|
[讨论]IDA Pro代码破解揭秘
另外,IDA PRO 权威指南及其第二版也是非常好的书;要把IDA 用好用精非读它不可,少了这本书,自己钻研IDA的许多高级功能也相当花时间。 |
|
[讨论]IDA Pro代码破解揭秘
51cto 站点的下载频道有 IDA PRO 代码破解揭秘的 PDF 版,以及该书的配套源码资源 具体可以访问 down.51cto.com 下面是我搜到的资源列表 |
|
各种HTTPS站点的SSL证书 ,密钥交换和身份验证机制汇总(含SSL握手实战!)
补充内容 最后要提一点,在上面这些站点中,facebook 在 HTTPS 方面的安全配置做得最好,此话怎讲? 例如,我们下载并且安装了 BurpSuite 开发公司的 SSL 证书(PostSwigger CA)作为本地操作系统上的“受信任的根证书颁发机构”: ,那么原则上 BurpSuite 将在浏览器与服务器中间充当 SSL 代理,当浏览器与 facebook 进行 TLS 握手时, BurpSuite 拦截浏览器的 TLS client hello 握手包,修改一些密钥交换参数,(其中的密钥交换算法,TLS 版本协商均可以在 BurpSuite 中配置): ;然后 BurpSuite 转发 TLS client hello 握手包到 facebook 服务器,冒充浏览器与服务器协商各种加密参数,并且进行密钥交换,这样 BurpSuite 就可以“剥掉”与 facebook 的加密流量并通过其接口显示给用户(还记得吗,之前我们用 wireshark 捕获的 HTTPS 流量是加密的,不能查看明文),BurpSuite 接收到服务器发送的证书后,用自己的 PostSwigger CA 根证书对 facebook的服务器证书“重签名”,这样,原本签发 facebook 证书的证书颁发机构,就变成了 PostSwigger CA (参考上图的“签发给”与“签发者”),然后将 Certificate 握手包转发给客户端。这都是为了取得浏览器的信任,然后浏览器会将 BurpSuite 当成 facebook 服务器(接受证书),无顾虑的与其进行 HTTPS 通信。如此一来,BurpSuite 就能够在中间透明地解密,转发 HTTPS 流量,并向用户显示解密后的信息。这就是 SSL 代理能够“剥掉”SSL 流量的原因。 上面这一招对普通的 HTTPS 站点有效,例如 https://www.google.com.tw ,但是对 facebook 则无效,因为 facebook 使用了“HTTPS 严格传输安全”(HTTPS Strict-Transport-Security,HSTS),强制要求浏览器使用 HTTPS 与其进行通信,不能提供给用户忽略有问题的证书的选项。而实际上也是如此,在使用 BurpSuite 充当中间 SSL 代理时,Chrome 与 FireFox 都不会“上当”,它们知道服务器(BurpSuite )返回的证书是伪造的,因此拒绝与其建立 HTTPS 连接,并且遵循 HSTS 规范,禁止用户忽略有问题的证书: 但是唯有 IE 例外,它还向用户提供忽略选项,甚至最新版本也是如此,这就给我们用 BurpSuite “欺骗”IE 提供了机会,最终 BurpSuite 可以捕获并解密 IE 与 facebook 之间的 HTTPS 流量。取代 wireshark 完成任务: 最后,使用 BurpSuite 拦截 IE 与 facebook 站点之间的 HTTPS 流量时,我们可以“实时”修改 facebook 返回的 HTTPS 响应,去掉其中的 Strict-Transport-Security 响应头部及其值,然后转发给浏览器,这样可以观察 IE 对于该响应头的处理方式: |
|
[原创]Windows下的无线热点蜜罐
蜜罐通常是用来引诱入侵者与攻击者上钩,进而对其调查,取证,并将其阻挡在外的部署环境。而这里讲的免费的馅饼wi-fi热点,更像是无线钓鱼平台,引诱普通人上钩! |
|
[分享]《Windows 内核设计思想》看雪论坛独家连载,附PDF下载
话说只有访谈过windows系统架构师们的《深入解析windows操作系统》丛书才能窥探这个软件工程史上奇迹般的商业系统的设计思想,不过该书第6版下册中文版迟迟不出,是翻译遇到困难还是其它情况就不得而知了,现在考虑自行翻译阅读了 |
|
web基础设施知识;web前端安全攻防,客户端安全基础
补充内容 如果直接用 BurpSuite 拦截百度 web 服务器(下称 bws)返回的 HTTP 响应,利用 BurpSuite Proxy 的实时编辑功能,可以在响应体的 HTML 文本中插入自定义代码,然后再转发至客户端浏览器,这样后者将执行注入的代码,按照这种思路,就可以模拟出任何站点返回的页面被注入的场景,例如下面通过在 bws 返回的响应体的 HTML 页面中插入代码,将 bws 为访问站点的用户设置的 cookie 输出到页面上。通过这个示例可以看到 : 1。BurpSuite 在 web 安全以及渗透测试领域的强大威力; 2。服务器除了可以在响应头中设置 cookie 外,也可以在响应体中的 HTML 文档的 script 标签内设置 cookie,2 种方式设置的 cookie 会被总合起来作为当前页面文档的 cookie; 3。没有指定 HttpOnly 属性的任何 cookie ,在 FireFox 中均可以用 document.cookie 读取(Chrome 的沙箱模型对于 javascript 代码的执行环境有严格限制,即便没有设置 HttpOnly 属性,默认情况也不能读取页面文档的 cookie) 首先在 BurpSuite Proxy 拦截到的 bws 响应数据中,切换到 “HTML”视图,这将仅显示响应体中的 HTML 文档,然后在最底部的搜索框中输入“</head>”字符串,目的是定位其后的 body 元素,并且在该元素的现有 script 标签内部插入自定义代码,模拟注入场景: 另外,切换到 Headers 视图,可以看到由 bws 通过响应头设置的 cookie 有3个: 在 HTML 视图的底部搜索框输入“BAIDUID”字符串后回车,定位到在响应体的HTML 文档的 script 标签内设置 cookie 的部分,这是“官方”设置的,没有经过我们修改或添加;其中有一个 cookie 名称为“BD_UPN”解答了前面我们找不到该 cookie 具体是在那里被设置的疑问,原来是在响应体中: 接下来,点击 BurpSuite Proxy 选项卡下的 Intercept 子选项卡中的“Forward”按钮,将我们编辑好的 bws 响应数据包,转发至客户端,让浏览器渲染 HTML 页面,执行我们在其中添加的代码: 如前所述,由 bws 设置的 cookie 之所以能够被客户端 javascript 读取,乃是由于其没有添加 HttpOnly 属性,各位可以在用 BurpSuite Proxy 拦截响应时,向 cookie 中添加 HttpOnly 属性,再转发至客户端,观察脚本能否读写 cookie,另外,也可以用 chrome 测试,了解沙箱模型如何限制客户端 javascript 的执行环境,从而阻止读取 cookie。 |
|
web前端安全基础与攻防(续篇)
补充内容 《存储型 XSS 示例》 一些社交网站如 twitter 提供的站内短信功能,在其中会通过 a 标签的 href 属性值进行短信链接的导航,这个属性值是用户能够控制的输入数据,所以 twitter 对其进行了严格输入检查,编码,过滤等操作,主要是过滤尖括号以及 script,embed,object 等危害性元素。 假设用于生成短信链接的输入框的初始 HTML 代码如下: <a href="></a> 在上面场景中,攻击者想方设法要绕过 twitter 服务器的 XSS 过滤器,最终目的是让输入的攻击载荷存储在由服务器的 web 应用维护的,某个能够公开访问的“页面”(类似新浪微博的“广场”功能),其它用户访问这个页面时,XSS 漏洞在用户浏览器中触发,执行恶意脚本代码。由于上面提到的过滤规则,插入尖括号的方法已经不再适用,必须寻找新的方法来绕过,例如下面这个攻击载荷使用了众多web 前端黑客技术: 1。双引号元素属性闭合; 2。 onmouseover 事件结合 eval 函数执行任意代码; 3。对 URL 进行 UTF-16 编码绕过 XSS 防火墙; 4。利用社会工程学攻击来引诱用户点击链接; http://t.co@" style="font-size:99px;" onmouseover="eval(location.href='http:\u002f\u002fwww.baidu.com\u002f')" class/ 其中,邮件符号 @ 后面的第一个双引号用于闭合原始 HTML 代码中, 等号后面的第一个双引号,于是攻击者可以在后面插入自定义内容;style属性将字体增大到 99 像素,保证受害者能够“准确地”点击到具诱惑性的恶意链接; onmouseover 属性代表的事件在用户将鼠标指针移动到该元素(a 元素)范围内时触发,事件触发后,执行自定义代码,将当前文档的 URL 重定向到百度首页(这里经过我净化,实际的攻击载荷中,其 URL 肯定是由攻击者控制的站点上的恶意 .js 文件);需要注意,考虑到 twitter 的 XSS 防火墙可能会过滤以“http://”起始的字符串,因此使用 UTF-16 编码(\u002f)对恶意 URL 中的正斜杠(/)进行转义,这样就能绕过服务器的 XSS 防火墙(只要不是精确匹配,输入字串就能通过检查),关键在于,转义后的字符序列在作为 HTTP 的响应体内容返回至客户端后,浏览器会解码,还原成正斜杠,导致最终访问该 URL ;另外, onmouseover 属性的值必须是能够执行的函数或者代码快,这就是调用 eval 函数的目的;最后,使用 class 后面的正斜杠来注释掉原始 HTML 代码中的第二个双引号,避免浏览器因为语法错误而无法执行脚本。 为了增强链接的视觉诱惑性,我在 a 元素的 innerHTML 中,添加了名为“邀请码发放页面”的文本节点(请勿在论坛中尝试!),最终的注入效果(即存储到服务器上的漏洞页面)如下所示: <!DOCTYPE html> <html> <head> <meta http-equiv="Content-type" content="text/html;charset=UTF-8" /> <title>XssPayloadTest</title> </head> <body > <a href="http://t.co@" style="font-size:99px;" onmouseover="eval(location.href='http:\u002f\u002fwww.baidu.com\u002f')" class/">邀请码发放页面</a> </body> </html> 使用当前任意类型的最新版浏览器打开上面 HTML 文件,就会重定向到百度首页,这就完整的模拟出攻击载荷成功绕过,存储到服务器上,并且返回给客户端后,用户浏览器成功执行代码的场景,截图如下: |
|
web前端安全基础与攻防(续篇)
补充内容 HTML 文档的跨平台支持:根据不同的浏览器类型,执行不同的代码块 由于各种浏览器对于新的 HTML5 规范,以及 DOM 的支持,实现程度不一致,为了保证自己所编写的文档,以及其中的脚本代码能够在所有主流浏览器中正确运行,一种解决办法是:先判断浏览器类型,然后执行相应浏览器支持的代码块。实现这个功能的关键,在于浏览器的用户代理字串值,即 navigator.userAgent 实现逻辑如下: <!DOCTYPE html> <html> <head> <meta http-equiv="Content-type" content="text/html;charset=UTF-8" /> <title>XssPayloadTest</title> </head> <body> <script> document.write(navigator.userAgent); document.write("<br><br>"); var isIE = navigator.userAgent.indexOf('Trident') > 0; var isChrome = navigator.userAgent.indexOf('Chrome') > 0; var isFirefox = navigator.userAgent.indexOf('Firefox') > 0; var isOpera = navigator.userAgent.indexOf('OPR') > 0; if (isIE){ document.write('<b>您使用的是IE浏览器</b>'); }else if (isChrome){ if (isOpera){ document.write('<b>您使用的是Opera浏览器</b>'); }else{ document.write('<b>您使用的是Chrome浏览器</b>'); } }else if (isFirefox){ document.write('<b>您使用的是Firefox浏览器</b>'); }else{ document.write('<b>您使用的是其它浏览器</b>'); } </script> </body> </html> 这是一个非常简单的先判断然后输出用户使用的浏览器类型的页面。 第8行直接在当前页面输出打开该页面的浏览器的用户代理字串;第11~14行分别查找各种浏览器的用户代理字串中,能够唯一识别浏览器类型的关键词,这是由于,在早期的“浏览器世界大战”中,许多 web 页面的特定内容仅支持 Netscape Navigator 浏览器(网景公司的产品,其 “Mozilla” 字串就是它首创的,含义为“Mosaic Killer”,即浏览器鼻祖 Mosaic 的杀手),而其它品牌浏览器为了提高自身市场份额与竞争力,也在其用户代理中添加了“Mozilla”字串,用于告诉目标站点:“我是与 Mozilla 兼容的浏览器”,如此一来,站点就会返回原本仅响应给 Mozilla 浏览器的页面内容,而这个内容通常是比较丰富的; 最终效果就是, IE 浏览器的用户访问某站点获得的内容与 Netscape Navigator 浏览器的用户获得的内容一致,因为 IE 在它的用户代理字串中,添加了“Mozilla”字串。 其它浏览器相继模仿这个做法,导致通过“Mozilla”字串根本无法实际识别浏览器类型,所以,必须找到用户代理字串中,每个浏览器都不一样的关键词,这就是第11~14行代码的工作,例如第11行查找用户代理字串中的“Trident”,后者是 IE 浏览器的 HTML 渲染引擎内核代号,然后保存在一个变量中,第15~16行代码通过判断这个变量的值来输出用户使用的是 IE 浏览器(在实际开发时,应该把这里的内容替换成仅 IE 浏览器支持的页面代码,其它类型浏览器以此类推)。 另一方面,当前的 chrome 与 Opera 浏览器的用户代理字串中,都包含了“Chrome”关键词,所以仅凭它无法区分这2个浏览器,需要检查在包含“Chrome”关键词的用户代理字串中,是否含有“OPR”字串,如果有,则能识别出 Opera 浏览器,反之,则为 chrome 浏览器;而这就是第17~22行的嵌套 if-else 语句的工作。顺便提一下,这2个浏览器的 HTML 解析引擎内核都源于苹果公司开发 Safari 浏览器时的内核 WebKit;google 公司在 WebKit 的基础上开发出新的内核称为 Blink;这2个浏览器厂商“饮水思源”的做法导致你在使用这2个浏览器打开上述文档时,看到了各自的用户代理字串都包含“AppleWebKit”: 我在第25~27行就停止了判断浏览器类型,你也可以继续添加判断其它浏览器的 else if 语句块,例如 Safari,以及国产的 360 浏览器,这需要预先找出能唯一标识它们的用户代理字串片断,就如第11~14行代码所做的一样,各位可以自行测试。 |
|
web前端安全基础与攻防(续篇)
补充内容 《页面使用 UTF-7 字符编码导致的 XSS 漏洞详解》 很多安全类书籍都介绍到 UTF-7 字符编码会导致 XSS 漏洞,但是部分内容各执一词,且描述不清楚,这里总结如下: UTF-7 编码是 unicode 编码的一类子集,后者包含的其它编码类型有 UTF-8,UTF-16LE(小端法,将代表编码字符的最低有效字节放在前面),UTF-16BE(大端法,将代表编码字符的最高有效字节放在前面),UTF-32LE,UTF-32BE 等等。在 UTF-7 编码方案中,左尖括号被编码成“+ADW-”;右尖括号被编码成“+AD4-”,其中的加号与减号分别标识着 UTF-7 编码序列的开始与结束;如果服务器端的 XSS 过滤器没有过滤这两个UTF-7 编码格式的左右尖括号,(或没有将其编码成其它无害形式的字符),并且客户端浏览器的版本过于老旧(例如 IE 7),那么当被注入攻击载荷的页面返回至客户端时,浏览器将解码 script 标签前后的 +ADW- 与 +AD4- 字符,还原成明文的左右尖括号,从而执行 script 标签内部的恶意代码: <!DOCTYPE html> <html> <head> <meta http-equiv="Content-type" content="text/html;charset=UTF-7" /> <title>XssPayloadTest</title> </head> <body> +ADW-script+AD4-alert("xss")+ADW-/script+AD4- </body> </html> 以上文档中,web 服务器(愚蠢到)在 meta 元素中显式指定字符集为 UTF-7,如果浏览器同样愚蠢(例如 IE 7以下版本,美其名曰是为了保持向后兼容)遵循这个设置字符集的指令,就会解码任何 UTF-7 字符,最终导致弹出提示框。需要补充说明的是,多数现代浏览器均已经不支持 UTF-7 了,因而上述文档在最新版本的三大浏览器中测试,都不会弹出提示框;另外,实际的触发环境和条件更为复杂,考虑如下场景中,假设用户的浏览器是 IE 6/7 : 1。如果 web 服务器在返回的 HTTP Content-Type 响应头中,没有明确设置字符集编码,并且响应体中的 HTML 文档中的 meta 元素内,也没有设置字符集编码,那么浏览器在碰到任何 UTF-7 字符时,都会尝试确定其编码方案,并且解码还原成明文字符,以上述文档为例,就会弹出提示框; 2。如果 web 服务器在返回的 HTTP Content-Type 响应头中,明确设置字符集编码为 UTF-8,并且响应体中的 HTML 文档中的 meta 元素内设置的字符编码为 UTF-7,那么浏览器最终将按照响应头中的设置(响应头的优先级比响应体中 meta 标签的优先级高 ),以上述文档为例,不会弹出提示框(因为采用 UTF-8 字符编码时,浏览器无法识别,解码 +ADW- 与 +AD4- 字符); 3。如果 web 服务器在返回的 HTTP Content-Type 响应头中,设置字符集编码为 UTF-7,并且响应体中的 HTML 文档中的 meta 元素内设置的字符编码为 UTF-8, 根据浏览器的采用优先级原则,上述文档将会弹出提示框; 总结,应对 UTF-7 XSS攻击,从最终用户防御的角度来看,应该确保浏览器总是处在当前的最新版本状态;从 web 站点防御的角度来看,应该明确在响应头与响应体的 HTML 文档中,设置字符编码为 UTF-8 或者其它安全的编码方案; 对于每个包含HTML内容的响应,web应用需要在其中包含 Content-type 头部,并且用“charset=”指令设置一个标准的,(浏览器)可辨识的字符集, 例如: Content-Type: text/html; charset=utf-8 或者: Content-Type: text/html; charset=ISO-8859-1 (如前所述,还要确保响应中的所有可能位置指定了相同的字符集) 并且过滤掉任何 UTF-7 危险字符,如果没有把握通过编程屏蔽所有危害字符,则可以模仿浏览器的 HTML 解析引擎将用户输入的内容在内存中保留一份副本,将其渲染成 HTML 页面,在渲染结果中查找任何明文的危害字符,对其进行编码过滤,然后再次渲染,再过滤,直到完全清除干净后,才可以把最终的文档返回给客户端。 (这也是许多优秀的服务器端 XSS 过滤器,WAF 采用的工作模式) |
|
web前端安全基础与攻防(续篇)
什么样的实验?你们是互联网公司还是安全公司 |
|
web基础设施知识;web前端安全攻防,客户端安全基础
论坛限制了每篇帖子引入的外链图片数量为40张,因此后续的内容和截图将在“续篇”帖中发表,敬请期待~ |
操作理由
RANk
{{ user_info.golds == '' ? 0 : user_info.golds }}
雪币
{{ experience }}
课程经验
{{ score }}
学习收益
{{study_duration_fmt}}
学习时长
基本信息
荣誉称号:
{{ honorary_title }}
能力排名:
No.{{ rank_num }}
等 级:
LV{{ rank_lv-100 }}
活跃值:
在线值:
浏览人数:{{ visits }}
最近活跃:{{ last_active_time }}
注册时间:{{ user_info.create_date_jsonfmt }}
勋章
兑换勋章
证书
证书查询 >
能力值