1.XSS攻击
跨站脚本攻击（Cross Site Scripting）是最普遍的Web应用安全漏洞。这类漏洞能够使得攻击者嵌入恶意脚本代码到正常用户会访问到的页面中，当正常用户访问该页面时，则可导致嵌入的恶意脚本代码的执行，从而达到恶意攻击用户的目的。
1.1 反射型XSS
反射性XSS有称为非持久型XSS（Non-Persistent XSS）。当某个站点存在XSS漏洞时，这种攻击会通过URL注入攻击脚本，只有当用户访问这个URL是才会执行攻击脚本。
1.1.1 URL请求串、请求体中的参数值在响应中展示，并且没有正确转码
1.1.1.1 特征描述
对URL请求串、请求体中的参数用特殊字符（> < ’ “ & /等）进行赋值，响应报文中未对这些特殊字符进行转码
1.1.1.2 风险
Cookie劫持，可导致攻击者以受害者的账号访问系统
XSRF，以受害者的账号权限发送请求，如果受害者是管理员，可能被利用创建一个新管理员账号供攻击者使用
钓鱼获取受害者的账号密码
获取受害者的部分信息，如操作系统、浏览器信息、访问过的网站、IP等
发起XSS蠕虫，快速感染挣个系统用户
DDOS，可以把所有受害者机器变成肉鸡对其他网站发起DDOS攻击
1.1.1.4 解决方案
对URL请求串、请求体中的参数使用正则表达式进行严格的校验
设置HttpOnly以避免cookie劫持的危险。
使用HTTP通讯是，Cookie中的重要或敏感信息应设置secure属性。（当web服务支持HTTP，不支持HTTPS时无法使用此属性，应避免传输敏感信息）
Cookie真内鬼domain、path属性设置应合理，Cookie中domain默认值为当前访问网站的域，无业务需求禁止修改
在响应报文中对特殊字符进行转码，常见的html转码如下：
& --> &
< --> <
–> >
" --> "
’ --> ’
/ --> /
1.1.2 跟踪Spring MVC方法的入参值（或者bean对象的属性值），存在未正确转码直接输出的情况
1.1.2.1 特征描述
Spring MVC框架会自动将请求串的值对应到java函数的入参，用特殊字符（> < ’ “ & /等）进行赋值，响应报文中未对这些特殊字符进行转码
1.1.2.2 风险
JavaScript被执行，危害同模式1。
1.1.2.3 解决方案
对Spring MVC方法的入参使用正则表达式进行严格的参数校验
在响应报文中对特殊字符进行转码
设置HttpOnly以避免cookie劫持的危险。
注：某些场景下即使做了HTML转码，也会存在XSS
1.2 DOM型XSS
客户端JavaScript可以访问浏览器的DOM文本对象模型是利用的前提，当确认客户端代码中有DOM型XSS漏洞时，并且能诱使(钓鱼)一名用户访问自己构造的URL，就说明可以在受害者的客户端注入恶意脚本。利用步骤和反射型很类似，但是唯一的区别就是，构造的URL参数不用发送到服务器端，可以达到绕过WAF、躲避服务端的检测效果。
DOM型XSS发生在浏览器端。
1.2.1 在JavaScript中，通过获取URL参数的API将其值直接输出到DOM
1.2.1.1 特征描述
在JavaScript中，获取URL参数的API大致有location.search()，location.hash()，location.href()，document.URL()，document.URLUnencoded()，document.referer()等，其值直接输出到DOM。
1.2.1.2 风险
JavaScript被执行，危害同反射型XSS --> 模式1。
1.2.1.3 解决方案
对于输入到DOM中的值，要进行校验，对于特殊字符需要进行转码。转码规则参考反射性XSS -> 解决方案。
对于跳转类的方法，需要校验其参数是否为正常的URL。
设置HttpOnly以避免cookie劫持的危险。
1.2.2 在JavaScript中，添加到DOM的API参数可通过url控制
1.2.2.1 特征描述
在JavaScript中，获取到URL参数后要添加到DOM中才能在页面中展示。添加到DOM的API大致有document.write()，document.writeIn()，.innerHTML=，.outerHTML=，.html()等，其参数可通过URL进行控制。
1.2.2.2 风险
JavaScript被执行，危害同反射型XSS --> 模式1。
1.2.2.3 解决方案
对于输入到DOM中的值，要进行校验，对于特殊字符需要进行转码。转码规则参考反射性XSS -> 解决方案。
当业务需要必须得将用户输入的数据放入html，那就要尽量使用安全的方法，比如innerText(),testContent()等。在使用框架时尽量使用框架自带的安全函数。
设置HttpOnly以避免cookie劫持的危险。
1.2.3 在JavaScript中，获取到URL参数后直接作为JS执行
1.2.3.1 特征描述
在JavaScript中，获取到URL参数后直接作为JS执行，JS中将字符串作为JS的API有eval()，execScript()，setInterval()，setTimeout()，Function()等，其参数可通过URL控制。
1.2.3.2 风险
JavaScript被执行，危害同反射型XSS --> 模式1。
1.2.3.3 解决方案
在开发过程中，避免此类方式的使用。
如业务需求，需要过滤特定的字符，包括双引号，单引号，反引号，等于号，小括号，点，加减乘除，和一些特殊的字符，例如name,top,parent,opener等等。
设置HttpOnly以避免cookie劫持的危险。
注：某些场景下即使做了HTML转码，也会存在XSS
1.3 存储型XSS
攻击者事先将恶意代码上传或储存到漏洞服务器中，只要受害者浏览包含此恶意代码的页面就会执行恶意代码。这就意味着只要访问了这个页面的访客，都有可能会执行这段恶意脚本，因此储存型XSS的危害会更大。因为存储型XSS的代码存在于网页的代码中，可以说是永久型的。
1.3.1 URL请求串、请求体重的参数值在响应中展示，并且没有正确转码
1.3.1.1 特征描述
对URL请求串、请求体中的参数用特殊字符（> < ’ “ & /等）进行赋值，响应报文中未对这些特殊字符进行转码
1.3.1.2 风险
JavaScript被执行，危害同反射型XSS --> 模式1。
1.3.1.3 解决方案
对URL请求串、请求体中的参数使用正则表达式进行严格的校验
在响应报文中对特殊字符进行转码，转码规则参考反射性XSS -> 解决方案。
设置HttpOnly以避免cookie劫持的危险。
1.3.2 HTTP请求头的参数（如Referer、User-Agent、X-Forward-For）的值入库，并且未正确转码在某些页面展示
1.3.2.1 特征描述
很多页面功能会提取请求头的值进行展示，如Referer可获取该请求头的来源，User-Agent可获取用户使用的浏览器信息，X-Forwarded-For获取用户IP，那么这些请求头的值都可以被用来进行XSS攻击。
1.3.2.2 风险
JavaScript被执行，危害同反射型XSS --> 模式1。
1.3.2.3 解决方案
对HTTP请求头参数使用正则表达式进行严格的校验
WEB端在进行展示前，需要对特殊字符进行转码，转码规则参考反射性XSS -> 解决方案。
设置HttpOnly以避免cookie劫持的危险。
1.3.3 文件上传功能，文件内容或文件名在响应中展示，并且未正确转码
1.3.3.1 特征描述
有一些上传功能，会将文件内容进行展示，如excel上传，会提取其内容并展示成表格，上传出错时提示信息可能会展示文件名。
另外，有些上传功能不一定在当前测试王元，但是文件内容或文件名的展示在当前测试网元，也可能存在存储型XSS。
1.3.3.2 风险
JavaScript被执行，危害同反射型XSS --> 模式1。
1.3.3.3 解决方案
对接口的参数进行严格的校验，如文件名等，同时对接口的响应报文对特殊字符进行转码。
WEB端在进行展示前，需要对特殊字符进行转码，转码规则参考反射性XSS -> 解决方案。
设置HttpOnly以避免cookie劫持的危险。
注：某些场景下即使做了HTML转码，也会存在XSS
1.4 绕过利用
有些XSS防御并不是通过HTML转码，而是通过特殊字符过滤的方式进行防御。可参考：https://www.fujieace.com/penetration-test/xss-100.html。
2.CSRF
跨站请求伪造（Cross—Site Request Forgery），用户在非自己本意的情况下，页面访问了非本站点的请求。
2.1 CSRF攻击攻击原理及过程
用户C打开浏览器，访问受信任网站A，输入用户名和密码请求登录网站A；
在用户信息通过验证后，网站A产生Cookie信息并返回给浏览器，此时用户登录网站A成功，可以正常发送请求到网站A；
用户未退出网站A之前，在同一浏览器中，打开一个TAB页访问网站B；
网站B接收到用户请求后，返回一些攻击性代码，并发出一个请求要求访问第三方站点A；
2.2 风险
可以导致WEB蠕虫
攻击者利用CSRF新建系统管理员，之后登录操作系统
修改或删除系统重要资源
2.3 解决方案
校验HTTP请求头包含referer字段，判断是否是从本站点发起的请求。
1）Referer的提供依赖于浏览器，如果浏览器本身存在BUG会导致CSRF防御失效
2）有些用户微课防止隐私泄露，可能设置浏览器Referer字段的发送，导致正常功能无法使用。
可在请求中加入一个攻击者无法获取、无法猜解的token，后台对请求进行校验。此种方式对开发者要求较高，实现上可能会存在逻辑漏洞，导致CSRF防御被绕过。
token必须使用安全随机数生成，长度不少于24个字符（或192bits）24bytes或192bit，有效期必须小于或等于会话有效期
B/S架构中，token必须存在于页面表单隐藏字段或自定义HTTP header
对于系统敏感和关键操作，如数据的添加/修改/删除/上传以及开关配置等，请求必须使用token防止CSRF攻击（优选方案为每次提交请求后token要更新一次，至少要做到在每次会话创建是生成新的token）
自定义请求头（比如XMLRequest），通过服务端校验自定义请求头，来防御CSRF攻击。
B/S应用中，使用cookie维持会话时，可设置sameSite属性，该属性可以消减CSRF攻击的可能性。（该属性是在浏览器端生效，所以需要浏览器版本兼容）
用户首次通过账号密码登陆系统后，系统授权服务器茴香客户端发布RefreshToken和AccessToken，RefresToken可以作为授权凭据，代替用户账号密码保存在客户端中，并且具有很长的有效期。客户端可以使用RefreshToken从系统授权服务器中重新获取新的AccessToken和登录是相同操作授权。
系统的客户端（APP）在用户登录界面，必须支持用户选择是否开启持久型登录，默认此选项不启用。系统管理界面不允许提供用户持久型登录，非移动的客户端不建议提供用户持久型登录
界面必须提供主动登出机制，账号从界面主动登出后，服务端必须立即清除会话。对于B/S架构的场景，用户关闭浏览器后，允许服务端在会话超实惠再清除会话。对于C/S架构的场景，用户关闭客户端后，服务端必须立即清除会话。
服务端在隔间一定时间没有接收到来自客户端/浏览器的消息后，必须做出超时登出，且清除维持的会话信息。
对于被删除的账号，如果处于已登录状态，必须马上删除该账户的session信息，后续才注意均无效。
使用单点登录（SSO）系统的用户在用户退出时，要求SSO的portal和web应用中的会话和认证凭据都要注销
3.SSRF
服务端请求伪造攻击（Server-side Request Forgery）,是一种由攻击者构造形成由服务端发起请求的一个安全漏洞。一般情况下，SSRF是要目标网站的内部系统。
SSRF 形成的原因大都是由于服务端提供了从其他服务器应用获取数据的功能，且没有对目标地址做过滤与限制。比如从指定URL地址获取网页文本内容，加载指定地址的图片，文档，等等。
3.1 常见利用手段
对外网、服务器所在内网、本地进行端口扫描，获取一些服务的banner信息
攻击运行在内网或本地的应用程序（比如溢出）
对内网web应用进行指纹识别，通过访问默认文件实现
攻击内外网的web应用，主要使用get参数就可以实现攻击（比如struts2、sqli等）
利用file协议读取本地文件
3.2 风险
会导致内网信息泄露，如端口、内部IP信息泄露等
作为跳板，攻击内网
利用特殊协议如file、golpher等进行高级利用
3.3 URL地址过滤的绕过
http://www.baidu.com@10.10.10.10与http://10.10.10.10请求是相同的
IP地址转换成进制来访问
如果WEB服务简单的过滤参数中获取的URL地址，没有判断郑振访问的地址，是有可能被此两种方法绕过
3.4 解决方案
在代码里进行安全的白名单限制，对第三方的服务器以及网站地址进行过滤
增加严格参数校验，将客户请求的错误信息停止响应
禁止一些没必要的网站端口以及安全协议，仅允许http、https安全连接协议
如果业务需求向任意URL发送请求，需要请求前通过安全包提供的函数来判断，如果业务需要跟随302跳转，每次请求时都需要经过安全包函数判断
4.CRLF
CRLF是“回车+换行”(\r\n)的简称。
4.1 原理简介
在HTTP协议中，HTTPHeader与HTTPBody是用两个CRLF分隔的，浏览器就是根据这两个CRLF来取出HTTP内容并显示出来。所以，一旦控制HTTP消息头中的字符，注入一些恶意的换行，就能注入一些会话Cookie或者HTML代码，所以CRLFInjection又称为HTTPResponseSplitting，简称HRS。
由于web应用的日志会记录用户访问的URL，所以在用户的URL中注入CRLF，可能会未在假的日志，引发审计的问题。
4.2 风险
导致绕过浏览器安全策略，形成反射型XSS
导致不安全的跳转漏洞
4.3 解决方案
在请求进入到服务之前（如服务的请求拦截器中），将URL或者参数中会导致CRLF的字符进行替换。
导致CRLF的字符包括：
%7f
%08
%20
%0a
%0b
%0c
%0d
\n
\r
5.URL不安全的跳转
5.1 原理简介
可以通过对url的修改，来做到钓鱼攻击的目的。不安全的url跳转问题可能发生在一切执行了url地址跳转的地方。
如果后端采用了前端传进来的(可能是用户传参,或者之前预埋在前端页面的url地址)参数作为了跳转的目的地,而又没有做判断的话，就可能发生"跳错对象"的问题。
5.2 风险
导致产生网络钓鱼行为，让受害者误认为恶意网站为受害网站
导致可绕过部分安全软件的网址白名单功能
5.3 解决方案
理论上讲，url跳转属于CSRF的一种，我们需要对传入的URL做有效性的认证，保证该URL来自于正确的地方，限制的方式同防止CSRF一样可以包括：
Referer的限制
有效性验证Token
6.HTML5攻击
6.1 利用HTML5进行XSS攻击
6.1.1 原理简介
Web应用程序中使用XSS黑名单或在WAF等网络设备中使用XSS黑名单时，黑名单经常使用正则表达式对标签和属性进行匹配，攻击者可使用HTML5新标签和属性绕过黑名单防护进行XSS攻击。
HTML5新增的能够执行XSS脚本的标签：
语音标签和视频标签 和
HTML5新增的能够执行XSS脚本的属性：
formaction()、onformchange()、onforminput()、autofocus()等
6.1.2 风险
JavaScript被执行，危害同反射型XSS --> 模式1
6.1.3 解决方案
设置HttpOnly以避免cookie劫持的危险。
对于新增的标签和方法参数进行校验，将特殊字符进行替换。
6.2 利用HTML5进行会话劫持
CORS(Cross-Origin Resource Sharing) 跨域资源共享，为了构建高品质的网站，以及满足日益增长的用户需求，HTML5针对SOP(同源策略)放宽了一些限制，允许Ajax发起跨域的请求，浏览器是可以发起跨域请求的。
会话劫持（Session hijacking），这是一种通过获取用户Session ID后，使用该Session ID登录目标账号的攻击方法，此时攻击者实际上是使用了目标账户的有效Session。会话劫持的第一步是取得一个合法的会话标识来伪装成合法用户，因此需要保证会话标识不被泄漏。
6.2.1 原理简介
Shell of the Future是一个反向Web Shell处理工具（Reverse Web Shell handler）。利用XSS攻击或浏览器地址注入JavaScript之后，Shell of the Future可劫持会话。他利用了HTML5支持的Cross Origin Requests，可以绕过一些反会话劫持的防护，HTTP-Only限制的Cookie、绑定IP地址的会话ID。
6.2.2 风险
网页如果开启了跨域资源共享，可能导致一些反会话劫持的防护方法失效，从而使攻击者可以获取HTTP-Only限制的Cookie、绑定IP地址的会话ID等信息。
6.2.3 解决方案
关闭透明化Session ID。透明化Session ID指当浏览器中的Http请求没有使用Cookie来存放Session ID时，Session ID则使用URL来传递。
验证HTTP头部信息，在http访问头文件：[Accept-Charset、Accept-Encoding、Accept-Language、User-Agent]，浏览器一般发出的头部不会改，验证请求的一致性
加入Token校验。同样是用于检测请求的一致性，使攻击者即使获取了Session ID，也无法进行破坏，能够减少对系统造成的损失。
token需要设置有效时长，过期之后即不可用
内部服务设置白名单，只允许特定服务的域名能够访问
6.3 利用HTML5的COR特性窃取CSRF Token
6.3.1 原理简介
如果CSRF token的请求URL(GET请求)，利用前面提到的CORS协议，攻击者可以注入一个CSRF payload跨域请求到目标站点上。当然，利用的话需要服务端添加一个HTTP 头字段“origin”，并且需要设置该属性withCredentials为true。
以下列举一个简单的窃取示例：
某用户登录www.bank.com。
假设该站点有CSRF保护，即在表单提交的地方添加了隐藏的token，然后发送GET请求到服务端进行验证，如下：
3.攻击者通过email、IM聊天工具或其他方式发送一个恶意站点ww.attackersite.com
4.攻击者可以提交一个Ajax请求到www.bank.com并且执行一些操作，但是需要知道CSRF的token值。
5.所以攻击者需要窃取到token令牌，然后进行CSRF攻击。
6.攻击者编写了下面的一段代码，发送Ajax请求到ConfirmTransfer.jsp页面并接受其响应，在返回的数据包中搜索csrfToken，找到后，另外一个Ajax请求被发送，其中包含了CSRF token。
以上的一切操作全在后台进行，用户完全不知情，因此，在HTML5中，攻击者完全可能获取到CSRF TOKEN和执行一些操作。6.3.2 风险
防御CSRF攻击的token泄露，绕过CSRF防御，进行CSRF攻击
6.3.3 解决方案
内部服务设置白名单，只允许特定服务的域名能够访问
token需要设置有效时长，过期之后即不可用
6.4 利用HTML5进行内网攻击
6.4.1 原理简介
部署在内网的应用如果设置了Access-Control-Allow-Origin为*（允许所有人访问），可能导致攻击者可以访问到内网资源，进行内网端口扫描、信息收集、网络侦测等。
6.4.2 风险
导致内网信息泄露，使攻击者有机会进一步渗透内网
6.4.3 解决方案
内部服务设置白名单，只允许特定服务的域名能够访问
6.5 利用HTML5进行点击劫持攻击
6.5.1 原理简介
点击劫持（ClickJacking）是一种视觉上的欺骗手段。攻击者通过使用一个透明的iframe覆盖在一个网页上，然后诱使用户在该页面上进行操作，达到窃取用户信息或者劫持用户操作的目的。
HTML5新增了拖放API，拓展了点击劫持的范围。“拖拽劫持”的思路是诱使用户从隐藏的不可见iframe中“拖拽”出攻击者希望得到的数据，然后放到攻击者能够控制的另一个页面中，从而窃取数据。
6.5.2 风险
攻击者利用点击劫持攻击达到窃取用户信息或者劫持用户操作的目的。
6.5.3 解决方案
在页面响应中使用X-Frame-Options消息头，可以有效防止攻击者利用HTML5的点击劫持攻击。
X-Frame-Options可选值：
DENY：浏览器会拒绝当前页面加载任何frame页面；
SAMEORIGIN：frame页面的地址只能为同源域名下的页面；
ALLOW-FROM origin：允许frame加载的页面地址；
具体的设置方法：
Apache配置：
Header always append X-Frame-Options SAMEORIGIN
nginx配置：
add_header X-Frame-Options SAMEORIGIN;
IIS配置：
<system.webServer>
…
…
</system.webServer>
6.6 HTML5新特性引起的敏感信息泄露
6.6.1 原理简介
localStorage是持久性的数据存储，除非主动删除。数据可跨越多个窗口，无视当前会话，被同源中所有页面、所有会话共同访问、使用。且在localStorage和sessionStorage中数据是明文存储，如果存在敏感信息很容易泄露。
6.6.2 风险
由于localStorage和sessionStorage本身无防XSS的机制，且HTTPOnly对localStorage和sessionStorage无效，一旦出现XSS漏洞，存储在localStorage和sessionStorage里的数据容易被窃取，即使对敏感数据加密，一旦秘钥泄露，也将导致敏感数据泄露。
客户端上有本地访问权限的操作系统用户或程序也能访问localStorage，因此数据容易泄露。
6.6.3 解决方案
禁止使用localStorage和sessionStorage存储敏感信息
使用localStorage和sessionStorage存储的数据，需要及时删除
6.7 WEB SQL Database中的SQL注入
6.7.1 原理简介
和传统数据库一样，如果写入Web SQL Database和indexed database的数据用户可控时，可能存在SQL注入的风险
6.7.2 风险
可任意操作WEB SQL database和indexed database中的数据，可能导致存储在前端数据库中的信息泄露
可写入恶意的JavaScript代码，再配合XSS漏洞获取用户cookie等信息
6.2.3 解决方案
在设计应用程序时，完全使用参数化查询（Parameterized Query）来设计数据访问功能
加强对用户输入的检查，过滤特殊字符，比如and、union、select等等
权限做到严格区分，对于每个用户的权限只给到满足需求前提下的最小权限
对用户输入进行长度的校验，SQL注入语句一般较长，条件允许的情况下可以对长度限制
错误消息提示尽量不要暴露服务器一些敏感信息比如数据库、中间件和系统版本等
配置WAF等防御性工具
7.SQL注入
7.1 原理简介
若参数未经过预编译处理，则参数是SQL语句的组成部分（而非仅仅是SQL语句的数值），参数本身可以是SQL表达式，可进行求值/运算/查询扥SQL逻辑操作。
若输入参数进行了求值/运算/查询等SQL逻辑操作，则可确定该参数未经过预编译出， 所以该参数可SQL注入。
7.2 风险
使用SQL万能钥匙绕过系统认证登陆系统（SQL注入发生在登录验证处）
泄露系统数据库内存储的数据，包括敏感信息：如账号/口令、信用卡/银行卡信息、个人隐私信息
数据库内信息被非法篡改（包括修改、添加、删除数据）
应用系统被GetShell或者预留后门，导致主机被控制
7.3 解决方案
在设计应用程序时，完全使用参数化查询（Parameterized Query）来设计数据访问功能
加强对用户输入的检查，过滤特殊字符，比如and、union、select等等
权限做到严格区分，对于每个用户的权限只给到满足需求前提下的最小权限
对用户输入进行长度的校验，SQL注入语句一般较长，条件允许的情况下可以对长度限制
错误消息提示尽量不要暴露服务器一些敏感信息比如数据库、中间件和系统版本等
配置WAF等防御性工具
8.XML注入
XXE(XML External Entity Injection) 全称为 XML 外部实体注入，在解析外部实体的过程中，XML解析器可以根据URL中指定的方案（协议）来查询各种网络协议和服务（DNS，FTP，HTTP，SMB等）。 外部实体对于在文档中创建动态引用非常有用，这样对引用资源所做的任何更改都会在文档中自动更新。 但是，在处理外部实体时，可以针对应用程序启动许多攻击。 这些攻击包括泄露本地系统文件，这些文件可能包含密码和私人用户数据等敏感数据，或利用各种方案的网络访问功能来操纵内部应用程序。 通过将这些攻击与其他实现缺陷相结合，这些攻击的范围可以扩展到客户端内存损坏，任意代码执行，甚至服务中断，具体取决于这些攻击的上下文。
在 XML 中有 5 个预定义的实体引用：
& lt; < 小于
& gt; > 大于
& amp; & 和号
& apos; ’ 省略号
& quot; " 引号
注释：严格地讲，在 XML 中仅有字符 “<“和”&” 是非法的。省略号、引号和大于号是合法的，但是把它们替换为实体引用是个好的习惯。
XML有2种解析方式：DOM和SAX。二者的区别是DOM解析是根据xml的层级结构在内存中分配一个树形结构，把xml的标签，属性和文本都封装成对象，优点是很方便实现增删改操作，缺点是如果文件过大，造成内存溢出；SAX解析是采用事件驱动，边读边解析，从上到下，一行一行的解析，解析到某一个对象，返回对象名称，当SAX解析结束，不会保存任何XML文档的数据，这样做优点是如果文件过大，不会造成内存溢出，方便实现查询操作，缺点是不能实现增删改操作。
8.1 原理简介
当系统没有禁用外部实体解析功能，并且使用XML解析库是saxreader或是xerces时，当发现页面或者接口调用可以进行XML文件导入，包括单个XML文件，以及压缩包中的XML文件，服务器解析文件的时候，有可能为禁止引用外部实体，导致攻击者构造的恶意内容得到执行，对系统造成危害。
Office2007以及以上版本文件实际上是一个特定格式的zip文件，使用解压工具打开office文件之后，会发现这些以.xlsx/.docx/.pptx结尾的文件中包含的多个文件基本上都是XML格式。
SVG使用XML格式定义图形，必然存在XML文件的解析，在解析SVG定义的过程中，如果未禁用外部实体引用，可能存在XXE漏洞。
8.2 风险
读取任意文件、执行系统命令、探测内网端口、攻击内网网站等危害。通常直接的影响是读取任意文件以及拒绝服务攻击。
8.3 解决方案
使用开发语言提供的禁用外部实体的方法
//JAVA提供的禁用外部实体的方法 :
DocumentBuilderFactory dbf =DocumentBuilderFactory.newInstance();
dbf.setExpandEntityReferences(false);
//PHP提供的禁用外部实体的方法 ：
libxml_disable_entity_loader(true);
//Python提供的禁用外部实体的方法 ：
from lxml import etree
xmlData = etree.parse(xmlSource,etree.XMLParser(resolve_entities=False))
过滤用户提交的XML数据
11.1.2 风险
攻击者可获得执行OS命令的应用进程的用户权限。Web应用有可能将OS命令转发给更高权限的其他进程来执行，如果执行OS命令的进程是root权限，则攻击者也获得root权限。
11.1.3 解决方案
对传入的参数进行严格的校验，非法的命令或者额外拼接的命令不允许执行
权限做到严格区分，对于每个用户的权限只给到满足需求前提下的最小权限
11.2 上传压缩包并自动解压，注入软连接
硬链接是通过索引节点进行的链接。在Linux中，多个文件指向同一个索引节点是允许的，像这样的链接就是硬链接。硬链接只能在同一文件系统中的文件之间进行链接，不能对目录进行创建。
软链接（也叫符号链接）与硬链接不同，文件用户数据块中存放的内容是另一文件的路径名的指向。软链接就是一个普通文件，只是数据块内容有点特殊。软链接可对文件或目录创建。
11.2.1 原理简述
当web服务器或app服务器配置为支持访问软连接时，该攻击才可能成功。如Tomcat对Context设置为allowLinking=“true”（默认值为false）。
使用mklink /D或In -s创建指向目标文件或目录的软连接，将软连接文件放入压缩包，使用上传功能上传，如果可通过HTTP请求访问解压后的软连接（可能需要重启Tomcat服务器），则可访问到目标文件或目录。
11.2.2 风险
攻击者可以应用程序的权限访问服务器文件，导致信息泄露
11.2.3 解决方案
权限做到严格区分，对于每个用户的权限只给到满足需求前提下的最小权限
将web服务器或app服务器配置为不支持访问软连接
12.LDAP注入
LDAP(Lightweight Directory Access Protocol):轻量级目录访问协议，是一种在线目录访问协议，主要用于目录中资源的搜索和查询，是X.500的一种简便的实现。
LDAP不定义客户端和服务端的工作方式，但会定义客户端和服务端的通信方式，另外，LDAP还会定义LDAP数据库的访问权限及服务端数据的格式和属性。LDAP有三种基本的通信机制：没有处理的匿名访问；基本的用户名、密码形式的认证；使用SASL、SSL的安全认证方式。LDAP和很多其他协议一样，基于tcp/ip协议通信，注重服务的可用性、信息的保密性等等。部署了LDAP的应用不会直接访问目录中的内容，一般通过函数调用或者API，应用可以通过定义的C、Java的API进行访问，Java应用的访问方式为JNDI(Java Naming and Directory Interface)。
12.1 原理简述
AND注入：应用会构造由”&”操作符和用户引入的的参数组成的正常查询在LDAP目录中搜索
OR注入：应用会构造由”|”操作符和用户引入的的参数组成的正常查询在LDAP目录中搜索
LDAP盲注入：假设攻击者可以从服务器响应中推测出什么，尽管应用没有报出错信息，LDAP过滤器中注入的代码却生成了有效的响应或错误。攻击者可以利用这一行为向服务器问正确的或错误的问题。这种攻击称之为盲攻击。LDAP的盲注攻击比较慢但容易实施，因为它们基于二进制逻辑，能让攻击者从lDAP目录提取信息。
12.2 风险
信息泄露
根据查询语句的使用场景，攻击者可以越权活的系统数据或绕过登录认证
12.3 解决方案
权限做到严格区分，对于每个用户的权限只给到满足需求前提下的最小权限
加强对用户输入的检查，过滤特殊字符，如圆括号、星号、逻辑操作符、关系运操作符等
不要提示例如“密码错误”、“用户名错误”等有明确指示的信息
13.XPATH注入
XPath 即为 XML 路径语言，是 W3C XSLT 标准的主要元素，它是一种用来确定 XML（标准通用标记语言的子集）文档中某部分位置的语言。XPath是一种用来在内存中导航整个XML树的语言,它的设计初衷是作为一种面向XSLT和XPointer的语言,后来独立成了一种W3C标准。
13.1 原理简述
XPath注入攻击，是指利用XPath 解析器的松散输入和容错特性，能够在 URL、表单或其它信息上附带恶意的XPath 查询代码，以获得权限信息的访问权并更改这些信息。XPath注入攻击是针对Web服务应用新的攻击方法，它允许攻击者在事先不知道XPath查询相关知 识的情况下，通过XPath查询得到一个XML文档的完整内容。Xpath注入攻击本质上和SQL注入攻击是类似的，都是输入一些恶意的查询等代码字符串，从而对网站进行攻击。
XPath注入发生在当站点使用用户输入的信息来构造请求以获取XML数据。攻击者对站点发送经过特殊构造的信息来探究站点使用的XML是如何构造的，从而进一步获取正常途径下无法获取的数据。当XML数据被用作账户验证时，攻击者还可以提升他的权限。
xpath注入的原理其实和sql注入很像， XPath注入攻击主要是通过构建特殊的输入，这些输入往往是XPath语法中的一些组合，这些输入将作为参数传入Web 应用程序，通过执行XPath查询而执行入侵者想要的操作，但是，注入的对象不是数据库users表了，而是一个存储数据的XML文件。攻击者可以获取 XML 数据的组织结构，或者访问在正常情况下不允许访问的数据，如果 XML 数据被用于用户认证，那么攻击者就可以提升他的权限。因为xpath不存在访问控制，所以我们不会遇到许多在SQL注入中经常遇到的访问限制。XML 中没有访问控制或者用户认证，如果用户有权限使用 XPath 查询，并且之间没有防御系统或者查询语句没有被防御系统过滤，那么用户就能够访问整个 XML 文档。 注入出现的位置也就是cookie，headers，request parameters/input等。
XPath注入攻击利用两种技术，即XPath扫描和 XPath查询布尔化。通过该攻击，攻击者可以控制用来进行XPath查询的XML数据库。这种攻击可以有效地对付使用XPath查询（和XML数据库） 来执行身份验证、查找或者其它操作。XPath注入攻击同SQL注入攻击类似，但和SQL注入攻击相比较，XPath在以下方面具有优势。
（1） 广泛性。XPath注入攻击利用的是XPath语法，由于XPath是一种标准语言，因此只要是利用XPath语法的Web 应用程序如果未对输入的XPath查询做严格的处理都会存在XPath注入漏洞，所以可能在所有的XPath实现中都包含有该弱点，这和SQL注入攻击有 很大区别。在SQL注入攻击过程中根据数据库支持的SQL语言不同，注入攻击的实现可能不同。
（2） 危害性大。XPath语言几乎可以引用XML文档的所有部分，而这样的引用一般没有访问控制限制。但在SQL注入攻击中，一个“用户”的权限可能被限制到 某一特定的表、列或者查询，而XPath注入攻击可以保证得到完整的XML文档，即完整的数据库。只要Web服务应用具有基本的安全漏洞，即可构造针对 XPath应用的自动攻击。
13.2 风险
在URL及表单中提交恶意XPath代码，可获取到权限限制数据的访问权，并可修改这些数据；
泄露系统数据库内存储的数据，包括敏感信息：如账号/口令、信用卡/银行卡信息、个人隐私信息
逻辑以及认证被绕过
13.3 解决方案
加强对用户输入的检查，过滤特殊字符，对用户输入进行长度的校验
权限做到严格区分，对于每个用户的权限只给到满足需求前提下的最小权限
14.上传下载
WebShell就是以asp、PHP、jsp或者cgi等网页文件形式存在的一种命令执行环境，也可以将其称之为一种网页后门。攻击者在入侵了一个网站后，通常会将这些asp或php后门文件与网站服务器web目录下正常的网页文件混在一起，然后使用浏览器来访问这些后门，得到一个命令执行环境，以达到控制网站服务器的目的（可以上传下载或者修改文件，操作数据库，执行任意命令等）。
WebShell后门隐蔽较性高，可以轻松穿越防火墙，访问WebShell时不会留下系统日志，只会在网站的web日志中留下一些数据提交记录，没有经验的管理员不容易发现入侵痕迹。攻击者可以将WebShell隐藏在正常文件中并修改文件时间增强隐蔽性，也可以采用一些函数对WebShell进行编码或者拼接以规避检测。除此之外，通过一句话木马的小马来提交功能更强大的大马可以更容易通过应用本身的检测。
14.1 上传2007版本word或者excel功能时导致XXE漏洞
14.1.1 原理简述
Office2007以及以上版本文件实际上是一个特定格式的zip文件，使用解压工具打开office文件之后，会发现这些以.xlsx/.docx/.pptx结尾的文件中包含的多个文件基本上都是XML格式。
14.1.2 风险
攻击者可以获取一些敏感信息，导致信息泄露
14.1.3 解决方案
参考XML注入。
14.2 上传任意指定文件拓展名到可访问路径下
14.2.1 原理简述
上传功能在实现时未考虑安全问题，可以直接上传asp/php/jsp等可执行脚本文件，并且这个文件能够被解释执行，从而直接绕过认证可以直接获得web权限。
14.2.2 风险
攻击者可以上传任意文件，存在上传webshell，从而控制服务器风险。
14.2.3 解决方案
权限做到严格区分，对于每个用户的权限只给到满足需求前提下的最小权限
加强对用户上传的文件拓展名进行的校验，只允许具有满足需求的文件拓展名的文件进行上传
在判断文件类型时，可以结合使用MIME Type、后缀检查等方式。在文件类型检查中，强烈推荐白名单方式，黑名单的方式已经无数次被证明是不可靠的。此外，对于图片的处理，可以使用压缩函数或者resize函数，在处理图片的同时破坏图片中可能包含的HTML代码
文件上传的目录设置为不可执行
14.3 跨任意目录上传或下载文件
14.3.1 原理简述
在web应用程序中，许多功能通常都需要处理用户以文件或目录名提交的输入。一般情况下，这些输入会传递给接受文件路径的API，应用程序将在它对用户请求的响应中处理该API调用的结果。
如果用户提交的输入未经证正确的校验，如输入路径中包含"…/“以及其变种时未作处理，可以导致攻击者通过”…/"方式进入未经授权访问的目录，从未可读取敏感文件或是把webshell上传到可执行目录下。
14.3.2 风险
攻击者可以获取一些敏感信息，导致信息泄露。或上传webshell到指定目录执行，从而控制服务器。
14.3.4 解决方案
权限做到严格区分，对于每个用户的权限只给到满足需求前提下的最小权限
加强对用户上传的文件路径进行的校验，只允许用户上传到指定的路径，该目录设置为不可执行
在判断文件类型时，可以结合使用MIME Type、后缀检查等方式。在文件类型检查中，强烈推荐白名单方式，黑名单的方式已经无数次被证明是不可靠的。此外，对于图片的处理，可以使用压缩函数或者resize函数，在处理图片的同时破坏图片中可能包含的HTML代码
使用随机数改写文件名和文件路径，文件上传如果要执行代码，则需要用户能够访问到这个文件。在某些环境中，用户能上传，但不能访问。如果应用了随机数改写了文件名和路径，将极大地增加攻击的成本。再来就是像shell.php.rar.rar和crossdomain.xml这种文件，都将因为重命名而无法攻击。
14.4 上传高压缩比文件
14.4.1 原理简述
许多应用系统都允许上传压缩文件（如rar、zip）,并且有限制上传的压缩文件的大小，通过制作一个高压缩比1000的压缩文件，把几G的文件压缩成几M，这样就不超过系统限制的大小，并且在后台该文件进行解压时会对CPU、内存、磁盘造成巨大压力，从而导致拒绝服务攻击。
14.4.2 风险
应用系统被拒绝服务攻击。
14.4.3 解决方案
加强对用户上传的文件大小进行的校验，不允许用户上传过大的文件
不允许在程序中直接对压缩文件进行解压，解压前需要对文件解压后的大小进行校验，判断是否会导致拒绝服务攻击
public static long getZipTrueSize(String filePath) {
long size = 0;
ZipFile f;
try {
f = new ZipFile(filePath);
Enumeration<? extends ZipEntry> en = f.entries();
while (en.hasMoreElements()) {
size += en.nextElement().getSize();
}
} catch (IOException e) {
e.printStackTrace();
}
return size;
}
14.5 HTTP中PUT方法上传文件
14.5.1 原理简述
Web容器支持PUT、MOVE、COPY等不安全的HTTP方法，但权限配置存在问题，系统没有禁用HTTP的危险方法，用户可以直接从客户端向服务器传送数据来取代指定文档的内容，及攻击者可以通过PUT、COPY、MOVE上传脚本文件。
14.5.2 风险
上传webshell，进而控制系统
14.5.3 解决方案
权限做到严格区分，对于每个用户的权限只给到满足需求前提下的最小权限
加强对用户上传的文件路径进行的校验，只允许用户上传到指定的路径，该目录设置为不可执行
在判断文件类型时，可以结合使用MIME Type、后缀检查等方式。在文件类型检查中，强烈推荐白名单方式，黑名单的方式已经无数次被证明是不可靠的。此外，对于图片的处理，可以使用压缩函数或者resize函数，在处理图片的同时破坏图片中可能包含的HTML代码
使用随机数改写文件名和文件路径，文件上传如果要执行代码，则需要用户能够访问到这个文件。在某些环境中，用户能上传，但不能访问。如果应用了随机数改写了文件名和路径，将极大地增加攻击的成本。再来就是像shell.php.rar.rar和crossdomain.xml这种文件，都将因为重命名而无法攻击。
尽量避免使用PUT、MOVE、COPY等不安全的HTTP方法
14.6 JAVA控制台上传木马包
14.6.1 原理简述
如Tomcat、JBoss、Weblogic、Jeety等组件有管理控制台，通过这些控制台可以上传发布一个包含webshell的war包，可获得webshell。
常见Java中间件信息：
中间件名称 默认端口 默认口令 console目录
Tomcat 8080 tomcat:tomcat /manager/html
JBoss 8080 无认证或admin:admin /jmx-console/
WebLogic 7001 weblogic:weblogic /console/
Resin 8080/8443 admin:admin /resin-admin/
axis2 8080 admin:axis2 /axis2/
Websphere 9043 websphere:websphere /ibm/console
GlassGish 4848 admin:adminadmin /
Tongweb 8080 admin:tongweb /
JOnAs 9000 jadmin:jonas/tomcat:tomcat /jonasAdmin/
jeety 8080 admin:admin /
14.6.2 风险
上传webshell，进而控制系统
14.6.3 解决方案
禁止在公网环境使用中间件的默认端口和默认口令，必须进行修改
对于中间件的Console目录设置为不可执行
权限做到严格区分，对于每个用户的权限只给到满足需求前提下的最小权限
对于数据库、Tomcat、Apache等第三方或开源软件 ，建议使用单独的操作账号运行
15.认证授权
15.1 登陆认证绕过攻击
15.1.1 当服务端采用SQL查询校验认证信息时，可能存在SQL注入绕过
参考7.SQL注入。
15.1.2 当服务端采用XML数据库来存储认证信息，可能存在XPATH注入绕过
参考13.XPATH注入。
15.1.3 当服务端采用LDAP数据库来存储认证信息，可能存在LDAP注入绕过
参考12.LDAP注入。
15.1.4 对于任何系统，均可能存在尝试密码登陆绕过暴力穷举攻击
15.1.4.1 原理简介
若系统中不存在防暴力穷举攻击机制的系统，攻击者可通过软件进行暴力登录系统或者猜解用户名和密码。
15.1.4.2 风险
攻击者可以通过暴力破解已知用户名的密码，进而登陆系统，或通过暴力进行猜解用户名；或者攻击者可以绕过系统的验证码限制，进行暴力破解，进而登录任意已知用户的账户或者猜解用户名和密码。
15.1.4.3 解决方案
系统使用账号口令认证方式时，必须提供口令防暴力破解机制，保护措施可参考：1）锁定账号；2）锁定IP；3）登录延迟；4）验证码；5）超长口令+IP白名单+告警或日志
验证码必须为服务端生成的安全随机数，保证验证码一次有效且存在有效，失效的验证码及时销毁，验证码不能以任何形式输出在客户端以及Cookie中
产品如果提供了验证码机制来防止暴力破解，则必须保证验证码机制的有效性，防止 被绕过。常见的验证码被绕过的错误实现为：首次登录页面上不提供验证码，当认证失败N次后页面出现验证码，此时攻击者关闭浏览器重新打开浏览器登录时，页面不显示验证码，用户输入正确账号口令后即可马上成功登录，绕过验证码机制
限制单个IP、单个账号获取验证码的频率，防止因暴力破解造成资源的浪费
用户登录失败后，登录界面禁止提示“用户名不存在”、“口令必须是6位”、“用户名无效”之类的有助于攻击者利用猜解系统用户名/口令信息。
设置密码复杂度，对于低复杂度的密码提示用户不允许设置，口令复杂度必须在服务端进行校验
系统进行口令复杂度检查时应禁止用户使用弱口令字典中的扣。系统提供更新（维护）弱口令字段的机制
管理员将配置文件或数据库中某账号的口令密文删除后，禁止该账户以空口令进行登录
在服务端读取口令失败的情况下（如存储口令的配置文件损坏），系统禁止自动启用缺省口令
对于人机登录场景，不能使用“超长口令+IP白名单+告警或日志”的方式来防暴力破解，即“超长口令（大于等于16个字符，且满足口令复杂度的要求）+IP白名单+告警或日志”的方式只适用于机机接口的场景。
由于验证码的防暴力破解的能力较弱，所以要求在高风险场景下，不能仅使用“验证码”作为防暴力破解的方法，必须结合“锁定账号”、“锁定IP”、“登录延迟”中的一种方法来防保留破解
账号/IP锁定机制不能以单词会话来判断暴力破解攻击，要基于IP或者账户来判断攻击，而不是基于会话
对用户登录失败N次被锁定的情况，必须在服务端做账号锁定，而不能尽在前台界面做账号锁定，导致防暴力破解机制被绕过
15.1.5 对于在线系统，可能存在使用已知口令或初始口令攻击
15.1.5.1 风险
导致使用的默认密码的账号可以被攻击者拿下，危害系统安全。
15.1.5.2 解决方案
强制用户第一次登录必须修改密码，且多次修改的密码不能重复，不能使用系统默认密码。
系统自动生成的口令需满足口令复杂度的要求，且满足随机性要求
防暴力破解机制须默认开启
系统运行后，管理员新建/重置用户账号，必须设置口令或系统自动产生随机口令（以上口令都应满足口令复杂度要求）
15.2 Session认证绕过攻击
15.2.1 对需要认证的URL进行编码或者伪装绕过黑名单
15.2.1.1 原理简述
假设需要认证的URL为main.action，可以使用一下方法进行尝试绕过：
使用URL编码，如：/main.actio %6e?
使用;（分号，表示路径参数），如：/main.action;1.txt
使用… ，如：/aaa/…/main.action
使用./././. ，如：/././././main.action
15.2.1.2 风险
导致攻击者可以无需任何权限，即可访问需要授权的URL，导致系统的登录校验被绕过
15.2.1.3 解决方案
管理web的所有url必须经过认证，防止泄露关键数据
对URL进行鉴权（如匹配白名单）时要严格，避免鉴权被绕过（如URL金项链使用全匹配，如将contains方法换成equals方法，不能使用简单的包含某个字符串的匹配算法），且需要先对URL标准化后进行鉴权（如过滤URL里面的"…/"类目录操作相关字符，URL解码等）
对于WEB系统，应对用户同时建立的会话数做出限制，同一时刻只允许一个会话在线；统建建立的会话数达到限制时，用户再次登录应失败或被强制下线
B/S应使用HTTPS传输会话标识，C/S应使用TLS等加密传输会话标识。
B/S应用中，只允许使用Cookie方式维持会话，其他方式均不可以使用。采用restful架构提供服务接口，可以不强制要求。使用Cookie维持会话时，必须设置httponly属性，防止js读取cookie内容
15.2.2 利用不需要认证的URL绕过插入到需要认证的URL
15.2.2.1 原理简述
加入不需要认证的URL为login.do，可以使用一下方法进行尝试绕过：
可使用… ，如：/login.do/ …/main.do
可使用;（分号，表示路径参数），如：/main.action;login.do
15.2.2.2 风险
导致攻击者可以无需任何权限，即可访问需要授权的URL，导致系统的登录校验被绕过
15.2.2.3 解决方案
参考15.2.1.3解决方案
15.3 Session权限等级校验绕过攻击
15.3.1 原理简介
在一般的web系统中，会同时具有认证的过滤器和鉴权的过滤器，其中，鉴权的过滤器中一般同样会存在黑名单的session校验，即类似于requestURL.equals(“/main.action”)&&session.getAttribute(“username”).equals(“admin”)等类似的判断，因此可采用绕过认证同样的策来尝试绕过鉴权过滤器。
在一般的web系统中，会同时具有认证的过滤器和鉴权的过滤器，其中，鉴权的过滤器中一般同样会存在白名单的session校验，即类似于requestURL.contains(“/login.do”)&&chain.dofilter(request.response)等类似的判断，因此可采用绕过认证同样的策来尝试绕过鉴权过滤器。
正常已登录用户发送的请求中，cookie字段包括了类似userName=abcd、userID=12、level=1等类似的描述已登录用户身份标识的信息，尝试将这些身份标识修改为最高权限的用户身份标识，然后尝试使用该身份标识去访问高级别用户才能访问的url，判断是否访问成功。
15.3.2 风险
导致攻击者可以无需任何权限，即可访问需要授权的URL，导致系统的授权校验被绕过
15.3.3 解决方案
可在请求中加入一个攻击者无法获取、无法猜解的token，后台对请求进行校验。
服务器端在鉴权及业务处理时，应该使用服务端的会话中存储的信息进行相关处理（如用户名、用户ID、用户权限等）。
服务端必须对客户端的请求进合法性校验（如校验会话标识是否存在、会话标识是否与用户IP匹配等）
系统应支持“根据账号、角色、IP地址、时间等某一特征或者多种特征结合来确定是否允许通过认证建立认证后的会话”；常用方案：限制用户的登录地点或时间（如只允许admin通过指定的IP地址登录）。
禁止将会话标识符以GET参数进行传递；禁止在url中包含会话标识，禁止在日志或打印信息中暴露会话标识，如需打印，需要进行不可逆处理（如hash、使用* 替代）
必须对系统管理的人机借口提供认证机制（如管理员执行管理操作前应进行身份认证）；必须对系统管理跨信任域的机机接口提供认证机制；用户系统升级接口的接口属于管理接口，应提供认证机制。
服务端禁止使用客户端的验证结果来验证用户身份的合法性。
权限的鉴别必须在服务端进行控制，防止用户可以拦截修改请求绕过限制。禁止尽在前台对窗口控件做灰化或仅前台屏蔽操作页面，防止任意用户可在登录后通过直接构造并发送请求报文，绕过前台的限制。
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
