检测并修复OpenSSL Heartbleed漏洞

这个漏洞已经出来好长时间了,自己也一直没有能够引起重视,今天看到有一款扫描检测工具CROWDSTRIKE HEARTBLEED SCANNER可以检查主机是否存在此类漏洞,然后就下载下来试了试,结果本博客直接躺枪。想想还是别拖着了,遂动手修复,其实修复的过程很简单,这里简要说明如下:

由于我使用的是Debian系统,所以这里主要记录的是Debian系统下的OpenSSL升级。

对于图省事的朋友来说,下面的命令可以轻松解决大多数问题:

sudo apt-get update
sudo apt-get upgrade

这两句命令其中第二句将升级系统中所有可更新的软件,但是有过之前惨痛的服务器升级经历后我觉得还是不能轻举妄动,所以再查阅网络后我采取特定升级的方法:

sudo apt-get update
sudo apt-get install openssl libssl1.0.0

继续阅读

网络安全与个人隐私

最近又开始瞎忙起来了,现在正好在迁移服务器数据,网速龟慢,上次和同事讨论如何神不知鬼不觉的发帖子,一般技术宅肯定是找各种代理,然后用代理作为中转,这样真实的IP就会被隐藏,但是某些部门通过技术手段依旧可以追踪到你,因为他们可以知道你是什么时候登录的代理。好吧,问题在这里就复杂了,其实国外的项目Tor就是为匿名访问而诞生的,其主要的原理就是通过多个复杂节点分散流量达到混淆隐藏真实主机的目的,可惜的是因为某些原因Tor在国内无法正常使用。也想到通过肉鸡进行二次乃至多次代理来加大追踪难度,但是这实际上也导致自己操作变得困难,想想目前的网速,得不偿失,最后讨论的结果是:到地摊上购买一张匿名的手机卡(貌似现在都是实名的了),然后买个能上网的手机(便宜一点,最好非智能机),然后到某处蹭个WiFi,然后用手机上网发帖,完事后销毁手机和卡,这样看来确实天衣无缝,但是同事的一句话给我泼了冷水:你有没有考虑过公共场所星罗密布的监控探头?好吧,看来这条路子也是有风险的。

继续阅读

浅议Web在线交易系统涉及的安全场景

之前一次课程的作业,我想存着还不如贴出来供大家拍砖。当然很多是一些个人想法,可能叙述得比较乱,不当之处还望批评指正。

现有的简单的在线交易场景如下图所示:

简单在线交易流程示意图

其中涉及到的数据安全和个人隐私主要有:客户账户和密码,信用卡及相关个人信息。

继续阅读

Cookie安全及Cookie跟踪技术导致个人隐私的泄漏

这篇文章是我所选修课程的作业,简单介绍了XSS、Cookie、Web安全威胁和个人隐私泄露问题,个人见解仅供参考,如有不当之处还望批评指正。

大家上网肯定对于HTTP并不陌生,完整的网址开头大多就是以http://开始的(当然不全是,加密的SSL浏览技术的网址是以https://开头的),HTTP表明的就是Hypertext Transfer Protocol超文本传输协议,大多数网页就靠它传输并呈现在我们的面前了。

现在的问题在于HTTP是建立在TCP/IP基础上的,我们知道TCP/IP协议是无状态协议(Stateless),这里的无状态就是说TCP/IP协议不保存连接的客户端的状态,更通俗一点是TCP/IP比较健忘,比如刚才客户端通过TCP/IP对服务器发送了一条消息,然后断开连接后再一次的连接服务器再发一条消息,这里同样的客户端,服务器并不知道这两条消息来自同一客户端,每次连接的建立服务器将认为是新客户端发起的请求。

继续阅读

FireFox/IE(ClearAuthenticationCache)清除HTTP基本认证实现登出注销

对于HTTP基本认证我前一篇文章也有所介绍,但是一次认证后浏览器将会把认证信息保存一段时间以避免在下一次打开时再次认证,也就是说认证成功后每次请求需要认证的页面时浏览器都会附加认证信息,一般在请求头的Authorization节点,但是如果用户需要注销当前登录就略显麻烦了。

不过在IE下比尔叔叔为我们提供了一个便捷的方式,那就是JavaScript执行下面的代码:

document.execCommand("ClearAuthenticationCache")

试了下,IE下完全正常,如果说这么简单就解决这个问题的话,也太低估我们的浏览器大军了,FireFox和Chrome等非微软系的浏览器根本无视上面的代码,所以只有另辟蹊径了。

继续阅读

Python利用htpasswd配置mini_httpd的基本认证授权(Authorization Basic)

前面我讲解了如何将树莓派(Raspberry Pi)打造成无线路由,感觉每次通过命令ssh管理显麻烦,于是自己动手编写Web界面,主要是使用Python编写的CGI程序,这里用到了mini_httpd这款轻量的Web服务器,本来想装nginx的,但是想想还是精简一些吧,毕竟资源有限,况且Web管理界面仅我一个人访问。

CGI应用跑起来了,但问题来了,如何实现普通路由的那种打开页面就弹出输入用户名密码的对话框?

这里主要用到HTTP协议的一个知识,那就是HTTP基本认证

继续阅读

利用SQL注入获得教育考试院查询中心管理员账户密码

突然想起年初时到某省教育考试院查询考试成绩无意间发现的漏洞,通过漏洞可以获取管理员账号和密码哈希,后来提交到WooYun网站了,过了很长时间没有关注这个事情,今天偶然想起,于是去看看厂商处理得怎么样,当时漏洞提交的地址在《江苏教育考试院查询中心查询中心管理员账号密码泄露漏洞》,看样子厂商早已经修复了,漏洞细节早已经公开,我在这里再叙述一遍留作备忘吧。

漏洞所在URL地址http://stat.jseea.cn/jseea_query/input.do?catlog=1&database=21%2Cdb_169,通过测试猜测到江苏省教育考试中心查询系统采取分数据库操作,各个数据库的选择通过Query String参数database来实现,其中以database=21%2Cdb_169为例,21表示查询模板(用于生成各类表单供用户填写),%2C表示编码的逗号,db_169表示数据库名称,上述解码后为21,db_169,当数据库名称不存在时构造SQL语句出现错误,程序崩溃(显示Java错误)可以看到SQL语句:

继续阅读

关闭PHP Credits和隐藏的GUID图片Logo彩蛋的显示

今天在查询PHP官方手册时有两个函数php_logo_guidzend_logo_guid引起了我的兴趣,其函数原型以及返回内容如下:

string php_logo_guid ( void );
// Returns PHPE9568F34-D428-11d2-A769-00AA001ACF42
string zend_logo_guid ( void );
// Returns PHPE9568F35-D428-11d2-A769-00AA001ACF42

这两个函数返回的以PHPE95..开头字符串,这个字符串有什么用呢?比如php_logo_guid手册举了一个例子:

< ?php
 
echo '<img src="' . $_SERVER['PHP_SELF'] .
     '?=' . php_logo_guid() . '" alt="PHP Logo !" />';
 
?>

如果一切正常的话,页面会输出一个PHP Logo,实际上图片地址存在任意的php页面后跟?=PHPE9568F34-D428-11d2-A769-00AA001ACF42这样的guid串,如果PHP是默认配置的话每个PHP页面都能找到,比如说有index.php,可以尝试访问index.php?=PHPE9568F34-D428-11d2-A769-00AA001ACF42,再看一下zend_logo_guid显示的图片,现在有些眼熟了吧,没错这些图片都被phpinfo()输出信息所调用。

我们可以在PHP 源码的 ext/standard/info.h 中找到相关标识图片GUID的定义:

继续阅读

利用IE8/9浏览器XSS跨站攻击脚本筛选过滤特性(X-XSS-Protection)

恶意跨站脚本(Cross-Site Scripting)的危害想必大家都知道,除了做好服务器端的安全过滤外,现在我们还可以利用一下IE8或者IE9的新的安全特性,那就是跨站脚本筛选器(Cross-Site Scripting Filter)。

对于IE的跨站脚本筛选器可以先参考IEBlog的《IE8 Security Part IV: The XSS Filter》这篇文章做个详细了解。如果IE检测到了跨站脚本攻击,那么IE将对页面做相应的修改以阻止攻击的发生,比如说这里有个示例页面。当我点击Say Hello的时候,IE会将表单的XSS脚本POST到服务端页面,这时IE8及以上浏览器检测到了可能的XSS攻击,于是提示“Internet Explorer 已对此页面进行了修改,以帮助阻止跨站点脚本。”

继续阅读

博客被疑似自动化黑客工具攻击

就在刚才收到了WordPress的Login Lock报警邮件,IP地址为118.192.35.178尝试登录博客后台失败多次,并且IP地址已经被阻止,所尝试的用户名为88888\’。

顿觉奇怪,心想不会谁无聊蛋疼到想去通过程序漏洞尝试黑WP吧,至少WP有这么多朋友使用,加上官方强有力的支持,安全性还是有保障的。于是尝试搜索这个IP地址,果然被我找到了一些痕迹,主要是一些留言和评论板,基本上都是用户名为88888内容为空,或者用户名和内容都是88888。到这里,我心里稍稍有了点底,至少可以判断是自动化程序自动攻击的,然后看到那么多网站的帖子都有88888的痕迹,再推断是不是自动发贴机在作怪,就像WP里屡禁不止的垃圾评论一样,但是想想奇怪的是我垃圾评论里没有收到该IP类似的帖子,看来不仅仅是这么简单。

登录服务器,使用下面的命令导出和该IP相关的Nginx访问日志。

cd /var/log/nginx
cat *.log | grep 118.192.35.178 > /tmp/attack.log
cd /tmp
more attack.log

继续阅读