PhishTank 是互联网上免费提供恶意网址黑名单的组织之一,它的黑名单由世界各地的志愿者提供,且更新频繁。
1、XSS
1.1、 XSS简介
跨站脚本攻击，英文全称是Cross Site Script，本来缩写是CSS，但是为了和层叠样式表有所区分，所以在安全领域叫做“XSS”。
XSS攻击，通常指黑客通过“HTML注入”篡改了网页，插入了恶意的脚本，从而在用户浏览网页时，控制用户浏览器的一种攻击。
1.2、 XSS分类
XSS根据效果的不同可以分成如下几类
第一种类型：反射型XSS
反射型XSS只是简单地把用户输入的数据“反射”给浏览器。也就是说，黑客往往需要诱使用户“点击”一个恶意链接，才能攻击成功。反射型XSS也叫做"非持久型XSS"
第二种类型：存储型XSS
存储性XSS会把用户输入的数据“存储”在服务器端。这种XSS具有很强的稳定性。
比较常见的一个场景就是，黑客写下一篇包含有恶意javascript代码的博客文章，文章发表后，所有访问该博客文章的用户，都会在他们的浏览器中执行这段恶意的JavaScript代码。黑客把恶意的脚本保存到服务器端，所以这种XSS攻击就叫做“存储型XSS”。
2.3、XSS 攻击进阶
2.3.1、初探XSS Payload
XSS 攻击成功后，攻击者能够对用户当前浏览的页面植入恶意脚本，通过恶意脚本，控制用户的浏览器。这些用以完成各种具体功能的恶意脚本，被称为“XSS Payload”。
XSS Payload实际上就是JavaScript脚本(还可以是Flash或其他富客户端的脚本)，所以任何JavaScript脚本能实现的功能，XSS Payload都能做到。
一个最常见的XSS Payload，就是通过读取浏览器的Cookie对象，从而发起"Cookie劫持"攻击。
Cookie中一般加密保存了当前用户的登录凭证。Cookie如果丢失，往往意味着用户的登录凭证丢失。换句话说，攻击者可以不通过密码，而直接登录进用户的帐户。
2.3.2、强大的Payload
1、构造Get与Post请求
2、 XSS 钓鱼
XSS并非万能的，在前文的例子中，XSS的攻击过程都是在浏览器中通过javascript脚本自动进行的，也就是说，缺少“与用户交互”的过程。
对于验证码,XSS Payload可以通过读取页面内容,将验证码的图片URL发送到远程服务器上来实施---攻击者可以在远程XSS后台接收当前验证码的值返回给当前XSS Payload,从而绕过验证码。
通过收集软件的classid，就可以扫描出用户电脑中安装的软件列表，甚至包括软件的版本。
3、识别用户的浏览器
4、识别用户安装的软件
5、CSS History Hack
6、获取用户的真实IP地址
2.4 调试JavaScript
常用的调式JavaScript的工具，以及辅助测试工具有以下几种：
Firbug
IE 8 Developer
Fiddler
HttpWatch
2.5 XSS 构造技巧
XSS攻击威力巨大，但是在实际环境中，XSS的利用技巧比较复杂，本章将介绍一些常见的XSS攻击技巧，也是网站在设计安全方案时需要注意的地方。
2.5.1 利用字符编码
%c1"/;alert(/XSS/);//
2.5.2 绕过长度限制
"><script>alert(/XSS/)</script>
"onclick=alert(1)//
<img src ="a" onerror="alert(1)">
2.5.3 使用<base>标签
<body>
<base href="http://www.google.com"/>
<img src="/int1/en_ALL/images/srpr/logolw.png" />
</body>
2.6 XSS的防御
流行的浏览器都内置了一些对抗XSS的措施，比如Firefox的CSP、Noscript扩展，IE 8内置的XSS Filter等。而对于网站来说，也应该寻找优秀的解决方案，保护用户不被XSS攻击。
2.6.1 四两拨千斤：HttpOnly
浏览器将禁止页面的JavaScript访问带有HttpOnly属性的Cookie.
严格的说，HttpOnly并非为了对抗XSS---HttpOnly解决的是XSS后的Cookie劫持攻击。
XSS攻击带来的不光是Cookie劫持问题，还有窃取用户信息、模拟用户身份执行漕卒等诸多严重的后果。
2.6.2 输入检查
常见的Web漏洞如XSS、SQL Injection等，都要求攻击者构造一些特殊字符，这些特殊字符可能是正常用户不会用到的，所以输入检查就有存在的必要了。
输入检查的逻辑，必须放在服务器代码中实现。如果只是在客户端使用JavaScript进行输入检查，是很容易被攻击者绕过的。
在XSS的防御上，输入检查一般是检查用户输入的数据中是否包含一些特殊字符，如<、>、'、"等。如果发现存在特殊字符，则将这些字符过滤或者编码。
2.6.3 输出检查
安全的编码函数
只需要一种编码
2.6.4 正确地防御XSS
2.6.5 使用富文本
2.6.6 防御DOM Based XSS
2、 跨站点请求伪造(CSRF)
CSRF 的全名士Cross Site Request Forgery，翻译成中文就是跨站点请求伪造。
攻击者首先在自己的域构造一个页面：
其内容为：
<img src="http://blog.sohu.com/manage/entry.do?m=delete&id=156714243" />
使用了<img>标签，其地址指向了删除博客文章的链接。
攻击者诱使目标用户，也就是博主访问http://www.a.com/csrf.html这个页面，发现原来存在的标题为“test1”的博客文章，已经被删除了。
2.1 CSRF 进阶
2.2 CSRF 的防御
2.2.1 验证码
验证码被认为是对抗CSRF攻击最简洁而有效的防御方法。
CSRF 攻击的过程，往往是在用户不知情的情况下构造的网络请求。而验证码，则强制用户必须与应用进行交互，才能完成最终的请求。因此在通常情况下，验证码能够很好地遏制CSRF攻击。
2.2.2 Referer Check
Referer Check在互联网中最常见的应用就是“防止图片盗链”。同理，Referer Check也可以被用于检查请求是否来自合法的“源”。
2.2.3 Anti CSRF Token
现在业界对CSRF的防御，一直的做法是使用一个Token。在介绍此方法前，先了解一下CSRF的本质。
3、点击劫持(ClickJacking)
点击劫持是一种视觉上的欺骗手段。攻击者使用一个透明的、不可见的iframe，覆盖在一个网页上，然后诱使用户在网页上进行操作，此时用户将在不知情的情况下点击透明的iframe页面。通过调整iframe页面上的位置，可以诱使用户恰好点击在iframe页面的一些功能性按钮上。
Flash点击劫持
图片覆盖攻击
拖拽劫持与数据窃取
触屏劫持
3.1 防御ClickJacking
ClickJacking是一种视觉上的欺骗，那么如何防御它？针对传统的ClickJacking，一般是禁止跨域的iframe来防范。
3.1.1 frame busting
通常可以写一段JavaScript代码，以禁止iframe的嵌套。这种方法叫frame busting。
3.1.2 X-Frame_options
因为frame busting存在被绕过的可能，所以我们需要寻找其他更好的解决方案。一个比较好的方案是使用一个HTTP头---X-Frame-Options
X-Frame-Options可以说是为了解决ClickJacking而生的，当值为DENY时，浏览器会拒绝当前页面加载任何frame页面：若值为SAMEORIGIN则Frame页面的地址只能为同源域名下的页面：若值为ALLOW-FROM，则可以定义允许frame加载的页面地址。
4、注入攻击
注入攻击的本质，是把用户输入的数据当做代码执行。这里有两个关键条件，第一个是用户能够控制输入；第二个是原本程序要执行的代码，拼接了用户输入的数据。
4.1、 SQL注入
在SQL注入的过程中，如果网站的Web服务器开启了错误回显，则会为攻击者提供极大的便利，比如在参数中输入一个单引号“'”,引起执行查询的语法错误。服务器直接返回了错误信息。
4.1.1、盲注(Blind Injection)
所谓盲注就是在服务器没有错误回显时完成的注入攻击。服务器没有错误回显，对于攻击者来说缺少了非常重要的“调试信息”，所以攻击者必须找到一个方法来验证注入的SQL语句是否得到执行。
4.1.2 Timing Attack
4.2、 数据库攻击技巧
SQL注入是基于数据库的一种攻击。不同的数据库有着不同的功能、不同的语法和函数，因此针对不同的数据库，SQL注入的技巧也有所不同。
4.2.1、常见的攻击技巧
4.2.2、命令执行
在MySQL中，除了可以通过导出webshell间接地执行命令外，还可以利用“用户自定义函数”的技巧，即UDF来执行命令。
4.2.3 攻击存储过程
在MS SQL Server和Oracle数据库中，都有大量内置的存储过程，在注入攻击的过程中，存储工程将为攻击者提供很大的便利。
4.2.4 编码问题
不同的字符编码也可能会导致一些安全问题，在注入的历史上，增经出现过“基于字符集”的注入攻击技巧。
注入攻击中常常会用到单引号“、”、双引号““”等特殊字符。在应用中，开发者为了安全，经常会使用转义字符"\"来转义这些特殊字符。但当数据库使用了“宽字符集”时，可能会产生一些意想不到的漏洞。
4.2.5 SQL Column Truncation
4.3、正确地防御SQL注入
本章中分析了很多注入攻击的技巧，从防御的角度来看，要做的事情有两件：
(1) 找到所有的SQL注入漏洞
(2) 修补这些漏洞
4.3.1、使用预编译语句
4.3.2、使用存储过程
4.3.3、检察数据类型
4.3.4、使用安全函数
5、文件上传漏洞
文件上传漏洞是指用户上传了一个可执行的脚本文件，并通过此脚本文件获得了执行服务端命令的能力。
文件上传本身是一个正常业务需求，对于网站来说，很多时候也确实需要用户将文件上传到服务器。所以“文件上传”本身没什么问题，但是问题的是文件上传后，服务器怎么处理、解释文件。如果服务器的处理逻辑做的不够安全，则会导致严重后果。
5.1、文件上传漏洞的概述
文件上传后导致的常见安全问题一般有：
上传文件时web脚本语言，服务器的web容器解释并执行了用户上传的脚本，导致代码执行。
上传文件是Flash的策略文件crossdomain.xml，黑客用以控制Flash在该域下的行为（其他通过类似方式控制策略文件的情况类似）；
上传文件是病毒、木马文件，黑客用以诱骗用户或者管理员下载执行；
上传文件是钓鱼图片或包含了脚本的图片，在某些版本的浏览器中会被作为脚本执行，被用于钓鱼和欺诈。
在大多数情况下，文件上传漏洞一般都是指“上传web脚本能够被服务器解析”的问题，也就是通常所说的webshell的问题。要完成这个攻击，要满足如下几个条件：
首先，上传的文件能够被web容器解析执行。所以文件上传后所在的目录要是web容器所覆盖到的路径。
其次，用户能够从web*问这个文件。如果文件上传了 ，但用户无法通过web访问，或者无法使得web容器解释这个脚本，那么也不能称之为漏洞。
最后，用户上传的文件若被安全检查、格式化、图片压缩等功能改变了内容，则也可能导致攻击不成功。
5.1.1 从FCKEditor文件上传漏洞谈起
5.1.2 绕过文件上传检查功能
5.2 功能还是漏洞
5.2.1 Apache文件解析问题
5.2.2 IIS文件解析问题
5.2.3 PHP CGI 路径解析问题
5.2.4 利用长传文件钓鱼
5.3 设计安全的文件上传功能
文件上传本身没错，只是在一些条件下会被攻击者利用，从而成为漏洞。根据攻击的原理，笔者结合实际经验总结了以下几点。
5.3.1 文件上传的目录设置为不可执行
只要web容器无法解析该目录下的文件，即使攻击者上传了脚本文件，服务器本身也不会受到影响，因此此点至关重要。
5.3.2 判断文件类型
在判断文件类型时，可以结合使用MIME Type、后缀检查等方式。在文件类型检查中，强烈推荐白名单的方式，黑名单的方式已经无数次被证明不可靠的。
5.3.3 使用随机数改写文件名和文件路径
文件上传如果要执行代码，则需要用户能够访问到这个文件。在某些环境中，用户能上传，但不能访问。如果应用使用随机数改写了文件名和路径，将极大地增加了攻击的成本。
5.3.4 单独设置文件服务器的域名
由于浏览器同源策略的关系，一系列客户端攻击将失效，比如crossdomain.xml、上传包含JavaScript的XSS利用等问题将得到解决。
6、 访问控制
“权限”一词在安全领域出现的频率很高。“权限”实际上是一种“能力”。对于权限的合理分配，一直是安全设计中的核心问题。
6.1 What can I Do?
权限控制，或者说访问控制，广泛应用于各个系统。抽象地说，都是某个主体对于某个客体需要实施某种操作，而系统对这种操作的限制就是权限控制。
在web应用中，根据访问客体的不同，常见的访问控制可以分为"基于URL的访问控制"、“基于方法的访问控制”和“基于数据的访问控制”。
6.2 垂直权限管理
访问控制实际上是建立用户与权限之间的对应关系，现在应用广泛的一种方法，就是“基于角色的访问控制”，简称RBAC。
不同角色的权限有高低之分。高权限角色访问低权限角色的资源往往是被允许的，而低权限角色访问高权限角色的资源往往则被禁止。如果一个本属于低权限角色的用户通过一些方法能够获得高权限角色的能力，则发生了“越权访问”。
6.3 水平权限管理
相对于垂直权限管理来说，水平权限问题出在同一个角色上。系统只验证了能访问数据的角色，即没有对角色内的用户做细分，也没有对数据的子集做细分，因此缺乏一个用户到数据之间的对应关系。由于水平权限管理是系统缺乏一个数据级的访问控制所造成的，因此水平权限管理又可以称之为“基于数据的访问控制”。
6.4 OAuth 简介
OAuth是一个在不提供用户名和密码的情况下，授权第三方应用访问web 资源的安全协议。
7 Web框架安全
8 应用层拒绝服务攻击
8.1 DDOS简介
8.2 应用层DDOS
8.2.1 CC攻击
CC攻击的原理非常简单，就是对一些消耗资源较大的应用层页面不断发起正常的请求，以达到消耗服务端资源的目的。
8.2.2 限制请求频率
8.2.3 验证码的那些事儿
8.3 耗尽资源攻击
8.3.1 Slowloris攻击
8.3.2 HTTP POST DOS
8.3.3 Server Limit Dos
9 Web Server配置安全
9.1 Apache 安全
9.2 Nginx 安全
9.3 jBoss远程命令执行
9.4 Tomcat远程命令执行
9.5 HTTP Parameter Pollution
10、撞库攻击
撞库可能是一个很专业的名词，但是理解起来却比较简单，撞库是黑客无聊的“恶作剧”，黑客通过收集互联网已经泄露的用户+密码信息，生成对应的字典表，尝试批量登陆其他网站后，得到一系列可以登陆的用户。
撞库攻击实质上就是，以大量的用户数据位基础，利用用户相同的注册习惯（相同的用户名和密码），尝试登陆其他网站。
11、失效的认证和会话管理
在进一步解释这种危险的漏洞之前，让我们了解一下身份认证和会话管理的基本知识。身份认证，最常见的是登录功能，往往是提交用户名和密码，在安全性要求更高的情况下，有防止密码暴力破解的验证码，基于客户端的证书，物理口令卡等等。
会话管理，HTTP本身是无状态的，利用会话管理机制来实现连接识别。身份认证的结果往往是获得一个令牌，通常放在cookie中，之后对用户的身份的识别根据这个授权的令牌进行识别，而不需要每次都登陆。
什么是失效的身份认证和会话管理？
用户身份认证和会话管理是一个应用程序中最关键的过程，有缺陷的设计会严重破坏这个过程。在开发Web应用程序时，开发人员往往只关注web应用程序所需的功能。由于这个原因，开发人员通常会建立自定义的认证和会话管理方案。但要正确实现这些方案却很难，结果这些自定义的方案往往在如下方面存在漏洞：退出、密码管理、超时、记住我、秘密问题、帐户更新等等。因为每一个实现都不同，要找出这些漏洞有时会很困难。
一些存在此漏洞的例子：
1、用户更改密码之前不验证用户，而是依靠会话的IP地址；
2、没有会话超时限制；
3、用户忘记密码后，密码找回功能太简单
例：应用程序超时设置不当。用户使用公共计算机访问网站。离开时，该用户没有电击退出，而是直接关闭浏览器。攻击者在一个小时后能使用相同的浏览器通过身份认证。
如何验证程序是否存在失效的认证和会话管理？
最需要保护的数据是认证凭证和会话ID。
1、当存储认证凭证时，是否总是使用hashing或加密保护
2、认证凭证是否可猜测，或者能够通过薄弱的帐户管理功能（例如帐户创建、密码修改、密码恢复，弱会话ID）重写
3、会话ID是否暴漏在URL（例如，URL重写）
4、会话ID是否容易受到会话固定(session fixation)的攻击
5、会话ID会超时吗？用户能退出吗？
6、注册成功后，会话ID会轮转吗？
7、密码、会话ID和其他认证凭据是否只通过TLS连接传输？
如何防范：
1、区分公共区域和受限区域
2、对最终用户帐户使用帐户锁定策略
3、支持密码有效性
4、能够禁用帐户
5、不要在用户存储中存储密码
6、要求使用强密码
7、不要在网络上以纯文本形式发送密码
8、保护身份验证Cookie
9、使用SSL保护会话身份验证Cookie
10、对身份验证Cookie的内容进行加密
11、限制会话寿命
12、避免未经授权访问会话状态
12 不安全的直接对象引用
所谓“不安全的对象直接引用”，意指一个已经授权的用户，通过更改访问时的一个参数，从而访问到了原本其并没有得到授权的对象。Web应用往往生成Web页面时会用它的真实名字，且不会对所有目标对象访问时来检查用户权限，所以这就造成了不安全的对象直接引用漏洞。
1、攻击者发现他自己的参数是6065，即？acct=6065
2、他可以直接更改参数为6066，即?acct=6066
3、这样他就可以直接看到6066用户的帐户信息了
如何防止不安全的直接对象引用的方法有以下两种：
1、使用非直接的对象引用---这防止了攻击者直接访问并未授权的对象，通过一种mapping或是其他的方法让攻击者无法直接访问。
2、检查访问---对每一个来自于不信任的源的直接对象引用都必须包含访问控制检查，从而确信该用户对该对象拥有访问权。
13 敏感信息泄露
信息泄露会暴露服务器的敏感信息，使攻击者能够通过泄露的信息进行进一步的入侵：
内容泄露漏洞
1、内网ip泄露
2、数据库信息泄露
3、网站调试信息泄露
4、网站目录结构邪路
5、绝对路径泄露
6、电子邮件邪路
文件泄露漏洞
1、帐号密码泄露
2、源码泄露
3、系统用户泄露
14、功能级访问控制缺失
概念
大多数web应用程序的功能在UI页面显示之前，会验证功能级别的访问权限。但是，应用程序需要在每个功能被访问时在服务器端执行相同的访问控制检查，如果请求没有验证，攻击者能够伪造请求从而在未经适当授权时访问功能。
功能级访问控制缺失的实例
对于登录页面，如果测试功能级访问控制是否缺失，需要测试：
1、合法的用户是否能够正常登录，访问到登录之后的页面。
2、匿名或者攻击者等没有权限的用户是否被拒绝登录，并且不能够访问需要登录才能访问到的页面。
功能级访问控制缺失的后果
会导致攻击者能够访问到正常用户才能访问的页面，如果是发生在后台，将对所有用户的安全问题造成威胁。
测试方法
1、保证合法授权用户可以访问成功
2、限制非法未授权用户的访问
防御措施
对一些需要权限才可以访问的目录、网页等做相应的验证处理，保证只有合法用户才可以访问，没有权限的用户给出相应的友好提示，提示信息业应当注意不能出现任何包含权限等信息的内容。
功能级的保护通过系统配置管理的，当系统配置错误时，开发人员必须作相同的代码检查，否则应用程序不能正确的保护页面请求，攻击者就是利用这种漏洞访问未经授权的功能模块。
很多系统的权限控制时通过页面灰化或隐藏URL实现的，没有在服务器端进行身份认证和权限验证，导致攻击者通过修改页面样式或获取隐藏的URL，进而获取特权页面来对系统进行攻击，或者在匿名状态下对他人的页面进行攻击，从而获取用户数据或提升权限。
此问题主要是系统在开发或者设计阶段，没有考虑攻击场景，以为看不到就是安全的，这种系统说白了是服务端没有进行权限控制和身份校验，才给了攻击者可乘之机。
15、未验证的重定向和转发
重定向和转发的区别
1、重定向是服务端根据逻辑，发送一个状态码，告诉浏览器重新去请求那个地址，所以地址栏显示的是新的URL。(重定向是客户端完成的)
2、转发是服务器请求资源，服务器直接访问目标地址的URL，把那个URL响应内容读取过来，然后把这些内容再发给浏览器，浏览器根本不知道服务器发送的内容从哪里来的，因为这个跳转过程是在服务端实现的，并不是在客户端实现的所以客户端并不知道这个跳转动作，所以它的地址还是原来的地址。(转发是在服务端完成的)
概念
在web应用中重定向是非常普遍的，并且通常情况下，重定向所引向的目的是带有用户输入参数的目的URL，而如果这些重定向未被验证，而攻击者就可以引导用户访问他们所要用户访问的站点。
转发也是极为普遍的，本质上转发是在同一个应用中对一个新页面发送请求，并且有时候是用参数来定义目标页面的，同样，如果参数未被验证，那么攻击者就可以通过其来绕过认证或是授权检查。
未验证的重定向和转发的影响
未验证的重定向和转发可能会使用户进入钓鱼网站，窃取用户信息等，对用户的信息以及财产安全造成严重的威胁。
未验证的重定向实例
如：http://www.example.com/member/login.jhtml?redirectUrl=http://www.shit.com/shit/a.asp
该链接没有限制redirecturl，免登陆获取了用户的nick后返回给第三方网站造成了漏洞的利用。
未验证的重定向和转发的测试方法
1、如果有代码：浏览器代码中含有重定向和转发的内容，看目的URL中是否包含用户输入参数，如果包含，观察目标参数是否在白名单之内，如果涉及到一些安全问题隐私等，需要重新定义目的URL
2、通过点击操作网站，观察是否产生重定向(HTTP响应代码300-307，通常是302)，观察在重定向之前用户输入的参数有没有出现在某一个URL或者很多URL中，如果是这种情况，需要改变URL的目标。
3、如果测试没有代码，检查所有参数，测试那些看起来像是重定向或者转发的页面。
举例：
登陆URL：http://www.example.com/member/login.jhtml
在URL后加参数如下：
http://www.example.com/member/login.jhtml?redirectUrl=http://www.google.cn
若跳转至谷歌就是没有做跳转的限制
未验证的重定向和转发的防御措施
1、尽量避免使用重定向和转发机制，如果使用了，那么在定义目标URL的时候不要包含用户参数
2、如果一定要保护输入的参数，那么：
对每个参数都必须进行验证以确保它的合法性和正确性，或是在服务端提供映射机制，将用户的选择参数转变为真正的白名单目标页面。