设计缺陷导致的后台沦陷

见：http://www.wooyun.org/bugs/wooyun-2013-019108

目录泄露（配置问题） ->
关键路径外网可见（没有身份验证）->
内网只通过X-FORWARD-FOR做验证（直接header欺骗绕过） ->
后台沦陷

Spamhaus DDoS

见：http://www.zdnet.com/the-largest-ddos-attack-didnt-break-the-internet-but-it-did-try-7000013225/

 

先10G -> 100G flood打Spamhaus

Spamhaus被打挂

 

Spamhaus找CloudFlare保护

 

向3w+个local dns请求ripe.net any，1:10放大攻击到320G

CloudFlare用23个清洗中心死扛

 

向CloudFlare的上游ISP发起攻击

影响到与其他国家通信的链路internet exchanges (IXs) 

 

url重定向死循环导致的DDOS

见：http://www.wooyun.org/bugs/wooyun-2013-017655

这个与技术无关，与逻辑有关。。。

底线是不断被刷新的

Flash ： 参数未过滤且allowscriptaccess=always导致的存储型XSS

见：http://www.wooyun.org/bugs/wooyun-2013-017699

首先，写html text的东东要过滤

其次，不要随便allowscriptaccess=always

flash 关键函数参数未做检查，导致XSS

见：http://www.wooyun.org/bugs/wooyun-2013-017728

ExternalInterface.call 调用前未检查传入参数，直接XSS

不做过滤直接调参数，基本上是直接沦陷 

Nginx解析漏洞 + 上传漏洞 ： 导致webshell

无法查看这则摘要。请 点击此处查看博文。

富文本编辑过滤不严导致存储型XSS

见：http://www.wooyun.org/bugs/wooyun-2013-017809

过滤了script，onerror，没有过滤onload

注意，白名单比黑名单可控

XSS : 手工定位的例子

见：http://www.wooyun.org/bugs/wooyun-2013-017521

漏洞本身不复杂，难得的是操作过程写得简单明白，个人认为是POC范文，哈哈

与FLASH的allowscriptaccess相关的存储型XSS

见：http://www.wooyun.org/bugs/wooyun-2012-013721


朋友网日志引用的flash object的allowscriptaccess设为always，只要 movie的value是 http://qzs.qq.com域名下即可执行

则，只要找到一个qzs.qq.com域名下的具有XSS缺陷的flash文件

即可结合，导致存储型XSS

XSS : 未过滤 \ 致使 \u0027 直接解释为 ' 导致闭合

见：http://www.wooyun.org/bugs/wooyun-2010-016437

过滤 ' ，但没过滤 \

用 \u0027 表示 '

解释执行时，产生 ' 闭合，导致XSS

CSRF : 关键请求直接GET没有POST没有TOKEN

参考：http://www.wooyun.org/bugs/wooyun-2013-017294

未加POST，未加TOKEN，直接采用GET，导致关键请求点击URL即可生效

Javascript : getAttribute后直接输出到innerHTML导致XSS

参考：http://www.wooyun.org/bugs/wooyun-2010-013677

getAttribute获取的内容会自动反转义

如果没有进行二次过滤，直接输出到innerHTML

会导致XSS漏洞

XSS DDOS 笔记

写超长COOKIE、写超长REQUEST FIELD：

http://hi.baidu.com/aullik5/blog/item/6947261e7eaeaac0a7866913.html

http://www.myhack58.com/Article/html/3/7/2011/30484_5.htm

XSS shell

http://labs.portcullis.co.uk/application/xssshell/

通过XSS漏洞，执行恶意js指令，生成随机url，通过img标签载入，重复随机请求，导致ddos受害网站

Apache Range Header DOS攻击 介绍

JS设置跨域Range字段失败，原因参看：

关于跨域的ajax——Cross-Origin Resource Sharing (CORS)

利用跨域资源共享（CORS）实现ajax跨域调用

<html>
<head></head>
<body>
<script>
var xhr = new XMLHttpRequest()
xhr.open("GET", "http://www.apache.org/", true);
xhr.setRequestHeader("Range", "bytes=0-100");
xhr.setRequestHeader("Accept-Encoding", "gzip");
xhr.send();
</script>
<h1>test</h1>
</body>
</html>

笔记 ：flash 安全

无法查看这则摘要。请 点击此处查看博文。

笔记：关于构造冲突串使hash退化为链表

论文：CrosbyWallach_UsenixSec2003.pdf

先汗一个，这论文都整出来多少年了……

问题在于各基础语言用的是“伪HASH”，桶长较小，冲突串容易构造。

加随机数初始化，且限制提交字符的串长度缓解。

参考：2007_28C3_Effective_DoS_on_web_application_platforms.pdf

perl的fix说明：perlsec.html#Algorithmic-Complexity-Attacks

perl5.8.1之后，大体上是加个随机种子PERL_HASH_SEED，且运行时一些操作可以动态改变hash值在桶内的位置，增加构造冲突串的复杂度。

由于这个随机处理，两次执行相同脚本，相同hash打出来的key顺序也不同。并且每次插入hash值也会导致key顺序发生变动。perl并不保证hash的key顺序一直固定。

可以把PERL_HASH_SEED置0，则不做随机处理，用于一些特殊的函数，如List::Util::shuffle()。

可以参考这个说明：http://perldoc.perl.org/Hash/Util.html

笔记：关于DNSCURVE

资料：

• Shaping DNS Security with Curves
• DNSCurve: Usable security for DNS
• CurveDNS

注意，DNSCURVE提供点到点的安全，而非端到端；也就是说，能保证采用DNSCURVE通信的相邻两节点DNS查询/应答通信数据的加密、认证。

DNSCURVE：

• 针对“NS”的公钥认证，维护成本较低；一个NS可以有多个公私钥对
• 挑战码+DH交换协商对称密钥，支持加密通信
• 客户端时间不准对解析结果无影响，抗重放攻击
• 不会降低外部探知整个域配置的难度
• 没有引入新RR，域名配置文件略微增大，主要是NS记录比以前长，可以继续用UDP
• 耗CPU的攻击威胁增大，每个包都要涉及加解密计算，否定缓存应答不需要特殊处理
• 放大攻击的风险较小

DNSSEC：

• 针对“域”的公钥认证，维护成本较高
• 不支持加密通信
• 客户端时间不准可能导致新公钥认证的域名配置被判为错误，需要NTP严格校准时间，会有重放攻击的问题
• NSEC/NSEC3会降低外部探知整个域配置的难度
• 引入新RR，域名配置文件显著变大，以后用TCP比较靠谱
• 耗CPU的攻击威胁增大，否定缓存应答需要特殊的临时计算
• 放大攻击的风险大增

 

二者可结合使用，例如，解析some.test.com，用DNSSEC认证“.”与“com.”，到test.com的ns再开始用DNSCURVE

opendns支持DNSCURVE

一些笔记

smurf 攻击：攻击源向一堆机器发源伪造的icmp包，导致一堆机器向受害机器回复ICMP包，最终受害机器挂掉。

ssl依赖于客户端信任服务器证书的程度，如果客户端信任一个伪造的证书，那么安全也无法保证。

setuid 临时提升普通用户权限

sticky bit : 用户对目录具有写权限时，能增加文件，不能删除文件

修改mac地址：ifconfig eth0 hw ether [MAC]

traceroute 中间有些跳是 ***，没有显示IP地址，原因是这些跳没有响应ICMP超时消息。如果从某一跳开始，后续所有跳都是***，有可能是带***的第一跳试图过滤返回该源IP的ICMP超时消息。

lsof -i 列出所有使用中的tcp/udp端口

tcpdump 参数：-nn 禁止协议查找；-c 捕获包数

交换机通过CAM(内容可寻址)存储器来保存和维护ARP缓存

arp 毒化：arp -s <受害者IP> <自身MAC> pub

混杂模式网卡: ifconfig 显示 PROMISC标识

Perl ：ARP中毒例子

见：Sam's Blog - ARP Poisoning with Perl

正常节点：

A, IP address: 192.168.1.100, MAC address: 00:e1:e2:e3:e4:e5
B, IP address: 192.168.1.1, MAC address: 00:f1:f2:f3:f4:f5

恶意节点的MAC地址：00:aa:bb:cc:dd:ee

中间人攻击的一种形式。

关于AAA

看到

What is the difference between authentication and authorization?

这里讨论了认证(authentication)和授权(authorization)的区别。

记得这是学计算机安全时syy讲的AAA protocol内容，应该还有个A，原来是审计(Accounting)。

认证(authentication)：验证用户身份是否合法。

授权(authorization)：检查用户是否有权执行某些操作。

审计(Accounting)：记录、统计用户消费的资源信息。