- 浏览: 313010 次
- 性别:
- 来自: 上海
最新评论
-
New_Mao_Er:
求最新的版本破解啊!!!
Omondo eclipseUML插件破解 -
konglx:
讲得仔细,谢了
全面分析 Spring 的编程式事务管理及声明式事务管理 -
cilendeng:
对所有post有效只能使用过滤器
说说Tomcat的Server.xml的URIEncoding=‘UTF-8’配置 -
jiulingchen:
mark了,灰常感谢!
JAVA中最方便的Unicode转换方法 -
anlaetion:
这算法可以有
js 字符串搜索算法
文章列表
nginx反向代理配置
- 博客分类:
- Nginx
location / {
#root html;
#index index.html index.htm;
proxy_cache rankCache;
proxy_cache_valid 200 301 302 304 1d;
proxy_cache_valid any 7d;
proxy_pass http://127.0.0.1:3000;
proxy_redirect off;
proxy_set_header ...
WiFi流量劫持—— 截获支付宝账号
- 博客分类:
- web安全
前两篇讲述了长缓存投毒的原理和实现。用户只要在我们的wifi下随便看个网页,就能植入一堆超长潜伏期的后门脚本。
究其原因,还是因为登陆页面的安全性不够。明文传输的网页,总是能轻而易举的注入脚本代码,因此存在风险也就不足为奇。
所以在必要的场合使用HTTPS加密传输,就能完全避免这类安全隐患。这意味着我们的入侵脚本对HTTPS无能为力了吗?
如果从数据解密的角度来说,确实如此。
尽管流量完全在我们的掌控之中,然而用户的私钥却在自己的内存里。我们只能眼睁睁的看着一个被锁着的保险箱在移来移去,却不知道里面藏着什么。
当然,这也不代表完全不能获取HTTPS里的数据。如果我 ...
WiFi流量劫持—— JS脚本缓存投毒
- 博客分类:
- web安全
在上一篇《WiFi流量劫持—— 浏览任意页面即可中毒》构思了一个时光机原型,让我们的脚本通过HTTP缓存机制,在未来的某个时刻被执行,因此我们可以实现超大范围的入侵了。
基于此原理,我们用NodeJS来实现一个简单的样例。得益于node强大的IO管理,以及各种封装好的网络模块,我们可以很容易实现这个想法:
开启一个特殊的DNS服务:所有域名都解析到我们的电脑上。并把Wifi的DHCP-DNS设置为我们的电脑IP。
之后连上Wifi的用户打开任何网站,请求都将被我们的node服务收到。我们根据http头中的host字段来转发到真正服务器上。
收到服务器返回的数据之后,我们就 ...
WiFi流量劫持—— 浏览任意页面即可中毒!
- 博客分类:
- web安全
大家都知道公共场所的Wifi安全性很差,但并不清楚究竟有多差。大多以为只要不上QQ、不登陆网站账号就没事了,看看新闻小说什么的应该毫无关系。
的确如此,看看新闻网页没有涉及任何敏感的账号信息。即便是数据明 ...
最近发现系统自带一个无线网卡驱动,可以用很简单命令创建一个无线网络接入点。有了这个免费虚拟的无线路由,我们可以尽情掌控手机的wifi数据了!抓包,嗅探,协议分析,流量劫持,代码注入。。。尽情发挥你想做的吧~
先从最简单的起,嗅探手机数据包。
WIN7下创建虚拟接入点很简单,只需两行命令:
netsh wlan set hostednetwork mode=allow ssid=APName key=password
netsh wlan start hostednetwork
保存为bat文件,用管理员模式运行,虚拟AP立即出现了!
记录刚刚在企鹅群里关于seajs的require和require.async的一段讨论过程。
再聊聊浏览器资源加载优化
- 博客分类:
- web performance
几乎每一个前端程序员都知道应该把script标签放在页面底部。关于这个经典的论述可以追溯到Nicholas的 High Performance Javasript 这本书的第一章Loading and Execution中,他之所以建议这么做是因为:
Put all <script> tags at the bottom of the page, just inside of the closing </body> tag. This ensures that the page can be almost completely rendered before s ...
CSS3的出现,他同时引进了一些新的单位,包括我们今天所说的rem。在W3C官网上是这样描述rem的——“font size of the root element” 。下面我们就一起来详细的了解rem。
前面说了“em”是相对于其父元素来设置字体大小的,这样就会存在一个问题,进行任何元素设置,都有可能需要知道他父元素的大小,在我们多次使用时,就会带来无法预知的错误风险。而rem是相对于根元素<html>,这样就意味着,我们只需要在根元素确定一个参考值,,在根元素中设置多大的字体,这完全可以根据您自己的需,大家也可以参考下图:
到目前为止,我们把能用前端脚本防御 XSS 的方案都列举了一遍。
尽管看起来似乎很复杂累赘,不过那些是理论探讨而已,在实际中未必要都实现。我们的目标只是为了预警,能发现问题就行,并非要做到滴水不漏的程度。
...
上一篇讲解了钩子程序的攻防实战,并实现了一套对框架页的监控方案,将防护作用到所有子页面。
到目前为止,我们防护的深度已经差不多,但广度还有所欠缺。
例如,我们的属性钩子只考虑了 setAttribute,却忽视还有类似的 setAttributeNode。尽管从来不用这方法,但并不意味人家不能使用。
例如,创建元素通常都是 createElement,事实上 createElementNS 同样也可以。甚至还可以利用现成的元素 cloneNode,也能达到目的。因此,这些都是边缘方法都是值得考虑的。
下面我们对之前讨论过的监控点,进行逐一审核。
内联事件执行 eval
昨天尝试了一系列的可疑模块拦截试验,尽管最终的方案还存在着一些兼容性问题,但大体思路已经明确了:
静态模块:使用 MutationObserver 扫描。
动态模块:通过 API 钩子来拦截路径属性。
提到钩子程序,大家会联想到传统应用程序里的 API Hook,以及各种外挂木马。当然,未必是系统函数,任何 CPU 指令都能被改写成跳转指令,以实现先运行自己的程序。
无论是在哪个层面,钩子程序的核心理念都是一样的:无需修改已有的程序,即可先执行我们的程序。
这是一种链式调用的模式。调用者无需关心上一级的细节,直管用就是了,即使有额外的操作对其也是不可见的。从最底层的指令拦截,到 ...
上一篇介绍的系统,虽然能防御简单的内联 XSS 代码,但想绕过还是很容易的。 由于是在前端防护,策略配置都能在源代码里找到,因此很快就能试出破解方案。并且攻击者可以屏蔽日志接口,在自己电脑上永不发出报警信息,保证测试时不会被发现。 昨天提到最简单并且最常见的 XSS 代码,就是加载站外的一个脚本文件。对于这种情况,关键字扫描就无能为力了,因为代码可以混淆的千变万化,我们看不出任何异常,只能将其放行。 因此,我们还需增加一套可疑模块跟踪系统。被动扫描 和之前说的一样,最简单的办法仍是遍历扫描。我们可以定时分析页面里的脚本元素,发现有站外地址的脚本就 ...
关于 XSS 怎样形成、如何注入、能做什么、如何防范,前人已有无数的探讨,这里就不再累述了。本文介绍的则是另一种预防思路。 几乎每篇谈论 XSS 的文章,结尾多少都会提到如何防止,然而大多万变不离其宗。要转义什么,要过滤什么,不要忘了什么之类的。尽管都是众所周知的道理,但 XSS 漏洞十几年来几乎从未中断过,不乏一些大网站也时常爆出,小网站更是家常便饭。预警系统 事实上,至今仍未有一劳永逸的解决方案,要避免它依旧使用最古老的土办法,逐个的过滤。然而人总有疏忽的时候,每当产品迭代更新时,难免会遗漏一些新字段,导致漏洞被引入。 即使圣人千虑也有一失,程序出 B ...
前面我们说到了反射性XSS的发掘,里面涉及了很多javascript的东西,也许有些孩童们看不懂里面的代码到底是什么回事。今天,我们就来认识一下什么是javascript。首先说之前要说明一点,javascript和Java半毛钱关系都没有,不要认为有一个Java就和Java有关,Javascript是一种由Netscape的LiveScript发展而来的一种客户端脚本语言。 在javascript是一种弱语言,没有强制的定义。 javascript一般存在于网站的html中的script标签中