OWASP Top 10

最新推荐文章于 2024-07-19 11:15:19 发布

Kevin_David_Mitnick

最新推荐文章于 2024-07-19 11:15:19 发布

阅读量543

点赞数

文章标签：安全 csrf xss

本文链接：https://blog.csdn.net/TH_DL/article/details/107359623

版权

OWASP Top 10

A1-注入

定义

简单来说，注入往往是应用程序缺少对输入进行安全性检查所引起的，攻击者把一些包含指令的数据发送给解释器，解释器会把收到的数据转换成指令执行。

注入攻击的本质：解释器把用户输入的数据当作代码执行。违背了数据与代码分离的原则这里有两个关键条件：

用户能够控制输入
原本程序要执行的代码，拼接了用户输入的数据

危害

注入能导致数据丢失或数据破坏、缺乏可审计性或是拒绝服务。注入漏洞有时甚至能导致完全接管主机。

SQL注入

如何判断注入

【最为经典的单引号判断法】：在参数后面加上单引号,比如:http://xxx/abc.php?id=1’如果页面返回错误，则存在 Sql
注入。原因是无论字符型还是整型都会因为单引号个数不匹配而报错。

【数字型判断】：当输入的参 x 为整型时，通常 abc.php 中 Sql 语句类型大致如下： select * from <表名>
where id = x 这种类型可以使用经典的 and 1=1 和 and 1=2 来判断：Url 地址中输入
http://xxx/abc.php?id= x and 1=1 页面依旧运行正常，继续进行下一步。Url 地址中继续输入
http://xxx/abc.php?id= x and 1=2 页面运行错误，则说明此 Sql 注入为数字型注入。原因如下：当输入
and 1=1时，后台执行 Sql 语句：select * from <表名> where id = x and 1=1
没有语法错误且逻辑判断为正确，所以返回正常。当输入 and 1=2时，后台执行 Sql 语句：select * from <表名>
where id = x and 1=2没有语法错误但是逻辑判断为假，所以返回错误。
我们再使用假设法：如果这是字符型注入的话，我们输入以上语句之后应该出现如下情况：select * from <表名> where id =
‘x and 1=1’ select * from <表名> where id = ‘x and 1=2’ 查询语句将 and
语句全部转换为了字符串，并没有进行 and 的逻辑判断，所以不会出现以上结果，故假设是不成立的。

【字符型判断】：当输入的参 x 为字符型时，通常 abc.php 中 SQL 语句类型大致如下： select * from <表名>
where id = ‘x’ 这种类型我们同样可以使用 and ‘1’='1 和 and ‘1’=‘2来判断：Url 地址中输入
http://xxx/abc.php?id= x’ and ‘1’=‘1 页面运行正常，继续进行下一步。Url 地址中继续输入
http://xxx/abc.php?id= x’ and ‘1’='2 页面运行错误，则说明此 Sql 注入为字符型注入。

盲注

盲注是在SQL注入攻击过程中，服务器关闭了错误回显，我们单纯通过服务器返回内容的变化来判断是否存在SQL注入和利用的方式。盲注的手段有两种：

一个是构造简单的条件语句通过页面的返回内容是否正确(boolean-based)，来验证是否存在注入。
一个是通过SQL语句处理时间的不同来判断是否存在注入(time-based)，在这里，可以用benchmark，sleep等造成延时效果的函数，也可以通过构造大笛卡儿积的联合查询表来达到延时的目的。RLIKE

数据库攻击技巧

构造简单的SQL语句进行注入获得信息
命令执行，利用“用户自定义函数”(UDF)来执行命令
攻击存储过程，如xp_cmdshell、sp_configure
编码问题(数据库，操作系统，Web应用所使用的字符集不统一)如：宽字节注入

宽字节注入产生原理以及根本原因

产生原理

在数据库使用了宽字符集（用多个字节来代表的字符称之为宽字符。）而WEB中没考虑这个问题的情况下，在WEB层，由于0XBF27是两个字符，在PHP中比如addslash和magic_quotes_gpc开启时，由于会对0x27单引号进行转义，因此0xbf27会变成0xbf5c27,而数据进入数据库中时，由于0XBF5C是一个另外的字符，因此\转义符号会被前面的bf带着"吃掉"，单引号由此逃逸出来可以用来闭合语句。

根本原因

character_set_client(客户端的字符集)和character_set_connection(连接层的字符集)不同,或转换函数如，iconv、mb_convert_encoding使用不当。

解决办法

统一数据库、Web应用、操作系统所使用的字符集，避免解析产生差异，最好都设置为UTF-8。
或对数据进行正确的转义，如mysql_real_escape_string+mysql_set_charset的使用。

SQL注入防御

使用预编译语句，绑定变量
使用安全的存储过程
检查数据类型
使用安全编码函数
使用安全的API
合理地分配数据库权限（最小权限原则）

API（Application Programming
Interface，应用程序接口）是一些预先定义的函数，或指软件系统不同组成部分衔接的约定。目的是提供应用程序与开发人员基于某软件或硬件得以访问一组例程的能力，而又无需访问原码，或理解内部工作机制的细节。

XML注入

XML是一种常用的标记语言，通过标签对数据进行结构化表示。

XML 指可扩展标记语言（EXtensible Markup Language）。
XML 是一种很像HTML的标记语言。
XML 的设计宗旨是传输数据，而不是显示数据。
XML 标签没有被预定义。您需要自行定义标签。
XML 被设计为具有自我描述性。
XML 是 W3C 的推荐标准。
XML 被设计用来传输和存储数据，其焦点是数据的内容。
HTML 被设计用来显示数据，其焦点是数据的外观。

防御：对用户输入数据中包含的“语言本身的保留字符”进行转义

代码注入

代码注入与命令注入往往都是由一些不安全的函数或者方法引起的，如eval(),system()等

防御：禁用危险函数（可参考开发语言的官方文档）

CRLF注入

CRLF：回车（ASCII 13，\r）换行（ASCII 10，\n）常做不用语义之间的分隔符。因此通过“注入CRLF字符”可改变语义。

漏洞利用

log注入，修改日志信息
注入HTTP头，通过两次CRLF注入到HTTP Body，一次CRLF注入修改HTTP头。

防御

处理好CRLF这两个保留字符即可。

外部实体注入攻击（XXE）

XXE注入，即XML External Entity，XML外部实体注入。通过 XML 实体，”SYSTEM”关键词导致 XML 解析器可以从本地文件或者远程 URI 中读取数据。所以攻击者可以通过 XML 实体传递自己构造的恶意值，使处理程序解析它。当引用外部实体时，通过构造恶意内容，可导致读取任意文件、执行系统命令、探测内网端口、攻击内网网站等危害。

漏洞原理

既然XML可以从外部读取DTD文件，那我们就自然地想到了如果将路径换成另一个文件的路径，那么服务器在解析这个XML的时候就会把那个文件的内容赋值给SYSTEM前面的根元素中，只要我们在XML中让前面的根元素的内容显示出来，不就可以读取那个文件的内容了。这就造成了一个任意文件读取的漏洞。

漏洞利用

1.任意文件读取

2.探测sql盲注

3.探测内网地址

防御

使用开发语言提供的禁用外部实体的方法

A2-失效的身份认证和会话管理

定义

与认证和会话管理相关的应用程序功能往往得不到正确实施，这就导致攻击者破坏密码、密匙、会话令牌或利用实施漏洞冒充其他用户身份。认证的目的是为了认出用户是谁，认证实际上就是一个验证凭证的过程。分为单因素认证与多因素认证。

危害

这些漏洞可能导致部分甚至全部帐户遭受攻击。一旦攻击成功，攻击者能执行合法用户的任何操作。因此特权帐户会造成更大的破坏。

以下情况可能产生漏洞：

用户身份验证凭证没有使用哈希或加密保护
认证凭证可猜测
会话ID暴露在URL里（例如, URL重写）
会话ID容易受到会话固定的攻击
会话ID没有超时限制，或者用户会话或身份验证令牌特别是单点登录令牌在用户注销时没有失效
成功注册后,会话ID没有轮转
密码、会话ID和其他认证凭据使用未加密连接传输

密码认证

优点：成本低，实现简单
缺点：安全性较差，需要足够安全的密码认证方案

要求

密码必须以不可逆的加密算法，或者是单向散列函数算法，加密后存储在数据库中。

彩虹表

用于破解MD5后密码的方法。

彩虹表实现原理

介绍彩虹表的原理之前，先简单说一下哈希加密算法。哈希（Hash）算法就是单向散列算法，它把某个较大的集合P映射到另一个较小的集合Q中，假如这个算法叫H，那么就有Q = H（P）。对于P中任何一个值p都有唯一确定的q与之对应，但是一个q可以对应多个p。作为一个有用的Hash算法，H还应该满足：H§速度比较快；给出一个q，很难算出一个p满足q = H§；给出一个p1，很难算出一个不等于p1的p2使得 H(p1)=H(p2)。

彩虹表的根本原理就是组合了暴力法和查表法，并在这两者之中取得一个折中，用我们可以承受的时间和存储空间进行破解。它的做法是，对于一个Q = H（P），建立另一个算法R使得 P = R(Q)，然后对于一个p，这样进行计算：

p0 -H-> q1 -R->p1 -H-> q2 -R->p2 -H-> q3 -R->p3 … -H-> q(n-1) -R->p(n-1) -H-> qn -R->pn

简单的说，就是把q用H、R依次迭代运算，最后得到pn，n可能比较大。最后我们把p0和pn都存储下来，把其他的结果都丢弃。然后用不同的p0代入计算，得到多个这样的p的对子。

彩虹表对应于上面钥匙与锁的例子就是，给你一把锁，你现在带了很多个钥匙串，每个钥匙串上面只有一两把钥匙。如果发现钥匙孔与其中某一个钥匙串上的钥匙形状类似，然后便用这把钥匙去磨出与钥匙孔类似的钥匙。

防御方法

“加盐”，即在密码特定位置插入特定字符串，这个特定字符串就是“盐”。“Salt”是一个随机字符串，它的作用是为了增加明文的复杂度，并使得彩虹表一类的攻击失效。Salt应该保存在服务器的配置文件中，并妥善保管。

有关彩虹表的详细详细介绍可看https://www.jianshu.com/p/131eddd18f6b

Session与认证

Session：当认证成功后，对用户透明的凭证。常加密后保存在cookie中，且受浏览器同源策略的保护。SessionID一旦在生命周期内被窃取，就等同于账户失窃。Session劫持，若SessionID保存在Cookie中则称为Cookie劫持。常见的Cookie泄露途径：XSS攻击、网络Sniff、本地木马窃取。此外SessionID还可保存在URL中，但安全性差。

Session的保护

生成Session是，需保证足够的随机性(采用足够强的伪随机数生成算法)。善于使用成熟的开发框架中的Cookie管理、Session管理的函数与功能。

Session Fixation攻击

会话固定攻击（session fixation attack）是利用应用系统在服务器的会话ID固定不变机制，借助他人用相同的会话ID获取认证和授权，然后利用该会话ID劫持他人的会话以成功冒充他人，造成会话固定攻击。

具体攻击过程

用户X(攻击者)先获取到一个未经认证的SessionID，然后将这个SessionID交给用户Y去认证，Y完成认证后，服务器并未更新此SessionID的值(Session改变，SessionID未改变)，所以X可以直接凭借此SessionID登录进Y的账户。

当SessionID保存在URL中时，才可能利用该攻击。

防御

登录完成后，重写SessionID
禁用客户端访问Cookie

单点登录(SSO)

单点登录英文全称Single Sign On，简称就是SSO。它的解释是：**在多个应用系统中，只需要登录一次，就可以访问其他相互信任的应用系统。**如OpenID。

优点

风险集中化，在单点处设计较为严格的安全方案
提高用户的效率。
用户不再被多次登录困扰，也不需要记住多个 ID 和密码。另外，用户忘记密码并求助于支持人员的情况也会减少。
提高开发人员的效率。
SSO 为开发人员提供了一个通用的身份验证框架。实际上，如果 SSO 机制是独立的，那么开发人员就完全不需要为身份验证操心。他们可以假设，只要对应用程序的请求附带一个用户名，身份验证就已经完成了。
简化管理。
如果应用程序加入了单点登录协议，管理用户帐号的负担就会减轻。简化的程度取决于应用程序，因为 SSO 只处理身份验证。所以，应用程序可能仍然需要设置用户的属性（比如访问特权）。

缺点

风险集中了，单点一旦被攻破，后果非常严重。
不利于重构
因为涉及到的系统很多，要重构必须要兼容所有的系统，可能很耗时。
无人看守桌面
因为只需要登录一次，所有的授权的应用系统都可以访问，可能导致一些很重要的信息泄露。

A3-跨站脚本

定义

当应用程序收到含有不可信的数据，在没有进行适当的验证和转义的情况下，就将它发送给一个网页浏览器，这就会产生跨站脚本攻击（Cross Site Scripting，简称XSS）。XSS允许攻击者在受害者的浏览器上执行脚本，从而劫持用户会话、危害网站、或者将用户转向至恶意网站。。

危害

攻击者能在受害者浏览器中执行脚本以劫持用户会话、迫害网站、插入恶意内容、重定向用户、使用恶意软件劫持用户浏览器等等。

XSS简介

XSS攻击：常指攻击者通过“HTML注入“篡改了网页，插入了恶意代码，从而在用户浏览网页时，控制用户浏览器的一种攻击方式。

反射型（非持久型XSS）

用户提交的数据中可以构造代码来执行，从而实现窃取用户信息等攻击。
即简单地把用户输入的数据“反射”给浏览器需要诱使用户“点击”一个恶意链接，才能攻击成功。

储存型

存储型XSS会把用户输入的数据“存储”在服务器端。
这种XSS具有很强的稳定性。

DOM型

通过修改页面的DOM节点形成的XSS，称之为DOM Based XSS。

Dom型的XSS是一些有安全意识的开发者弄出来的。比如说接受参数会做一些过滤，把一些字符转义一下，但是转义之后依然会存在着XSS的情况，比如说下图中，我们上面输入的可以看到这行代码规律，把这个大括号、小括号以及双页号进行转移，按理说转移之后它应该不会再作为它的标签存在，不会存在XSS的代码。

DOM 节点是指在XML文档中的每个成分都是一个节点。整个文档就是一个文档节点，每个XML标签是一个元素节点。

DOM型和反射型的区别

反射型XSS：通过诱导用户点击，我们构造好的恶意payload才会触发的XSS。
反射型XSS的检测:我们在每次请求带payload的链接时页面应该是会带有特定的畸形数据的。
DOM型：通过修改页面的DOM节点形成的XSS。 DOM-based
XSS由于是通过js代码进行dom操作产生的XSS，所以在请求的响应中我们甚至不一定会得到相应的畸形数据。根本区别在我看来是输出点的不同。

payload:在计算机安全中，有效载荷是恶意软件（如蠕虫或病毒）的一部分，它们执行恶意操作：删除数据、发送垃圾邮件或加密数据。除了有效载荷之外，这种恶意软件通常还具有旨在简单地传播自身或避免检测的开销代码。

漏洞利用

通过XSS攻击，进行“cookie劫持”（可通过HttpOnly防御）
通过XSS攻击，构造GET与POST请求
XSS钓鱼
通过XSS攻击，识别用户浏览器
通过XSS攻击，识别用户安装的软件
通过XSS攻击，获取用户的真实IP地址（通常借助第三方软件完成）
劫持用户会话从而执行任意操作，例如进行非法转账、强制发表日志、发送电子邮件等
网页挂马
进行恶意操作，例如任意篡改页面信息、删除文章等
进行大量的客户端攻击，如DDoS攻击

XSS攻击平台

Attack API
BeEF
XSS-Proxy

XSS蠕虫的产生条件

正常情况下，一个是产生XSS点的页面不属于self页面，用户之间产生交互行为的页面，都可能造成XSS Worm的产生。不一定需要存储型XSS。不过一般来说，用户之间发生交互行为的页面，如果存在存储型XSS，则比较容易发起XSS Worm。

典型代表：Samy Worm、百度空间蠕虫

XSS构造技巧

利用字符编码
绕过长度限制
使用标签
利用window.name构造

XSS的防御

输入检查（白名单）

输出检查

安全编码函数（在正确的地方使用正确的安全编码函数）

输入点检查：对用户输入的数据进行合法性检查，使用filter过滤敏感字符或对进行编码转义，针对特定类型数据进行格式检查。针对输入点的检查最好放在服务器端实现。

输出点检查：对变量输出到HTML页面中时，对输出内容进行编码转义，输出在HTML中时，对其进行HTMLEncode，如果输出在Javascript脚本中时，对其进行JavascriptEncode。

DOM型XSS的防御:

如果用户的输出点在

A4-不安全的直接对象引用（越权）

定义

所谓“不安全的对象直接引用”，即Insecure direct object references，意指一个已经授权的用户，通过更改访问时的一个参数，从而访问到了原本其并没有得到授权的对象。Web应用往往在生成Web页面时会用它的真实名字，且并不会对所有的目标对象访问时来检查用户权限，所以这就造成了不安全的对象直接引用的漏洞。

案例

URL: http://example.com/account/view?account=

1)攻击者发现他自己的参数是6065，即?account=6065

2)他可以直接更改参数为6066，即?acctount=6066

3)这样他就可以直接看到6066用户的账户信息了

URL: http://example.com/account/edit/{account id}/

解决

内部代码要判断数据集权限
使用基于用户或会话的间接对象访问，这样可防止攻击者直接攻击未授权资源
访问检查：对任何来自不受信源所使用的所有对象进行访问控制检查
避免在url或网页中直接引用内部文件名或数据库关键字
验证用户输入和url请求，拒绝包含./ …/的请求

水平权限管理

由于水平权限管理是系统却反一个数据级的访问控制所造成的，因此也称“基于数据的访问控制”

面临问题：难找、难区分、难修改

一个简单的数据级访问控制，可以考虑使用“用户组”概念。

A5-安全配置错误

描述

事实上，这个问题可能存在于Web应用的各个层次，譬如平台、Web服务器、应用服务器，系统框架，甚至是代码中。开发人员需要和网络管理人员共同确保所有层次都合理配置，有很多自动化的工具可以用于查找是否缺少补丁，错误的安全配置，缺省用户是否存在，不必要的服务等等。

案例

应用程序服务器管理员控制台自动安装后没有被删除。而默认帐户也没有被改变。攻击者在你的服务器上发现了标准的管理员页面，通过默认密码登录，从而接管了你的服务器。
目录列表在你的服务器上未被禁用。攻击者发现只需列出目录，她就可以找到你服务器上的任意文件。攻击者找到并下载所有已编译的Java类，她通过反编译获得了所有你的自定义代码。然后，她在你的应用程序中找到一个访问控制的严重漏洞。
应用服务器配置允许堆栈跟踪返回给用户，这样就暴露了潜在的漏洞。攻击者热衷于收集错误消息里提供的额外信息。
应用服务器自带的示例应用程序没有从您的生产服务器中删除。该示例应用有已知安全漏洞，攻击者可以利用这些漏洞破坏您的服务器。

您的应用程序是否对整个程序堆栈实施了恰当的安全加固措施？这些措施包括：

是否有软件没系统、Web/ 应用服务器、数据库管理系统、应用程序和其它所有的代码库文件。
是否使用或安装了不必要的功能（例如，端口、服务、网页、帐户、权限）？
默认帐户的密码是否仍然可用或没有更改？
你的错误处理设置是否防止堆栈跟踪和其他含有大量信息的错误消息被泄露?
你的开发框架（比如：Struts、Spring、ASP.NET）和库文件中的安全设置是否理解正确并配置恰当？

安全配置错误的防御措施

最小原则，移除不必要的功能、组件、文档和示例。
限制中间件管理界面、限制默认端口。
修改默认账户。
配置所有的安全机制
关掉所有不使用的服务
设置角色权限帐号
使用日志和警报
所有错误只显示友好信息，不显示任何与实际错误相关的信息

A6-敏感数据暴露

描述

许多Web应用程序没有正确保护敏感数据，如信用卡号，税务ID和身份验证凭据，email等。攻击者可能会窃取或篡改这些弱保护的数据以进行信用卡诈骗、身份窃取，已经猜测你的用户名和密码进行犯罪。敏感数据值需额外的保护，比如在存放或在传输过程中的加密，以及在与浏览器交换时进行特殊的预防措施。

首先你需要确认的是哪些数据是敏感数据而需要被加密。例如：密码、信用卡、医疗记录、个人信息应该被加密。在程序文件、配置文件、日志文件、备份文件及数据库中都有可能包含敏感数据。对于这些数据，要确保：

当这些数据被长期存储的时候，无论存储在哪里，它们是否都被加密，特别是对这些数据的备份？
无论内部数据还是外部数据，传输时是否是明文传输？在互联网中传输明文数据是非常危险的。
是否还在使用任何旧的或脆弱的加密算法？
加密密钥的生成是否是脆弱的，或者缺少恰当的密钥管理或缺少密钥回转？
当浏览器接收或发送敏感数据时，是否有浏览器安全问题。

常见场景

敏感信息存储
敏感信息传输
敏感信息显示
客户端代码注释
错误处理测试

测试方法

检测形式多样，工具爬虫扫描得到敏感文件的路径，从而找到敏感数据，
手工挖掘，根据web容器或者网页源代码的查看，找到敏感信息。

敏感信息泄露防护

应根据业务特点定义出系统存储的敏感信息。
敏感信息在存储、传输、显示时应进行安全处理，可采用的处理方式为加密或脱敏。
敏感信息不应使用GET方式提交到服务器。
用户密码为最高级别的敏感信息，在存储、传输、显示时都必须加密。
需要选择可靠的加密算法，优先选择不对称加密算法，不得使用BASE64等编码方式进行“加密”
对于一些系统默认报错页面应重新进行设计自定义报错页面，以免暴露系统敏感信息。

A7-功能级别访问控制缺失

描述

大多数Web应用程序在UI中可见以前验证功能级别的访问权限。但是，应用程序需要在每个功能被访问时在服务器端执行相同的访问控制检查。如果请求没有被验证，攻击者能够伪造请求以在未经适当授权时访问功能。

确定是否有此问题：
用户界面（UI）是否存在到未授权功能的导航？
服务器端的身份认证或授权功能是否完善？
服务器端的检查是否仅仅依赖于攻击者提供的信息？
是否有数据层面的校验，例如：客户A通过URL的方式访问客户B的信息。

防御

采用RBAC(Role Based Access Control)来限定功能访问。
对用户访问进行审计。
对数据集权限做编码处理。

RBAC基本思想是，对系统操作的各种权限不是直接授予具体的用户，而是在用户集合与权限集合之间建立一个角色集合。每一种角色对应一组相应的权限。一旦用户被分配了适当的角色后，该用户就拥有此角色的所有操作权限。这样做的好处是，不必在每次创建用户时都进行分配权限的操作，只要分配用户相应的角色即可，而且角色的权限变更比用户的权限变更要少得多，这样将简化用户的权限管理，减少系统的开销。

A8-跨站请求伪造

描述

CSRF(Cross-site request forgery)，一个跨站请求伪造攻击迫使登录用户的浏览器将伪造的
HTTP请求，包括该用户的会话cookie 和其他认证信息，发送到一个存在漏洞的web应用程
序。这就允许了攻击者迫使用户浏览器向存在漏洞的应用程序发送请求，而这些请求会被
应用程序认为是用户的合法请求。 [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传在这里插入图片描述

CSRF攻击是攻击者利用用户的身份操作用户账户的一种攻击方式。是由于在关键操作执行时，没有对操作是否由用户自愿发起进行确认，所导致的。造成该漏洞的本质原因是：重要操作的所有参数都是可以被攻击者猜测到的。

漏洞利用

攻击者盗用了用户的身份，以用户的名义发送恶意请求。CSRF能够做的事情包括：以用户名义发送邮件，发消息，盗取用户的账号，甚至于购买商品，虚拟货币转账…造成的问题包括：个人隐私泄露以及财产安全。

CSRF的防御

验证码
验证Referer
添加token（不可预测性原则)

token和referer做横向对比，谁安全等级高？

token安全等级更高，因为并不是任何服务器都可以取得referer，如果从HTTPS跳到HTTP，也不会发送referer。并且FLASH一些版本中可以自定义referer。
但是token的话，要保证其足够随机且不可泄露。(不可预测性原则)

针对token，对token测试会注意哪方面内容，会对token的哪方面进行测试？

针对token的攻击：
一是对它本身的攻击，重放测试一次性、分析加密规则、校验方式是否正确等
二是结合信息泄露漏洞对它的获取，结合着发起组合攻击

A9-使用含有已知漏洞的组件

描述

组件，比如：库文件、框架和其它软件模块，几乎总是以全部的权限运行。如果一个带有漏洞的组件被利用，这种攻击可以造成更为严重的数据丢失或服务器接管。应用程序使用带有已知漏洞的组件会破坏应用程序防御系统，并使一系列可能的攻击和影响成为可能。

示例

Apache CXF认证绕过——未能提供身份令牌的情况下，攻击者可以以最高权限调用任意的web服务。
Spring远程代码执行——滥用Spring中语言表达式的实现允许攻击者执行任意代码，有效的接管服务器。

防御

维护组件的版本列表，随时更新。
关掉不必要的端口和服务。及时移除不必要的依赖、组件、功能、文档等。
标识正在使用的所有组件的版本，包括所有依赖项
建立使用组件的安全策略，禁止使用未经安全评估的组件。
在适当情况下，对组件进行安全封装，精简不必要的功能，封装易受攻击部分
利用工具及时记录组件、库等版本信息，安全等级等、可考虑利用基线扫描软件来及时检测该部分信息
在保障业务正常进行的情况下，及时进行更新补丁操作，安装好相应的安全配置

A10-未验证的重定向和转发

描述

Web应用程序经常将用户重定向和转发到其他网页和网站，并且利用不可信的数据去判定目的页面。如果没有得到适当验证，攻击者可以重定向受害用户到钓鱼软件或恶意网站，或者使用转发去访问未授权的页面。

URL重定向和转发的区别

redirect是服务端根据逻辑,发送一个状态码,告诉浏览器重新去请求那个地址.所以地址栏显示的是新的URL。（重定向是在客户端完成的）

转发是服务器请求资源,服务器直接访问目标地址的URL,把那个URL的响应内容读取过来,然后把这些内容再发给浏览器.浏览器根本不知道服务器发送的内容从哪里来的,因为这个跳转过程实在服务器实现的，并不是在客户端实现的所以客户端并不知道这个跳转动作，所以它的地址栏还是原来的地址。（转发是在服务器端完成的）

未验证的redirectUrl和转发的概念

在Web应用中重定向是非常普遍的，并且通常情况下，重定向所引向的目的是带有用户输入参数的目的URL，而如果这些重定向未被验证，而攻击者就可以引导用户访问他们所要用户访问的站点。
转发也是极为普遍的，本质上转发是在同一个应用中对一个新页面发送请求，并且有时候是用参数来定义目标页面的。同样，如果参数未被验证，那么攻击者就可以通过其来绕过认证或是授权检查。

案例

应用程序有一个名为“redirect.jsp”的页面，该页面有一个参数名是“url”。攻击者精心制作一个恶意URL 将用户重定向到一个恶意网站，执行钓鱼攻击并安装恶意程序。
http://www.example.com/redirect.jsp?url=evil.com
应用程序使用转发在网站的不同部分之间发送请求。为了帮助实现这一功能，如果一个交易成功了的话，一些网页就会发送一个参数给用户，用于指定用户的下一个页面。在这种情况下,攻击者制作一个URL, 用于绕过应用程序的访问控制检查,并将他转发给一个他通常不能访问的管理功能。
http://www.example.com/boring.jsp?fwd=admin.jsp

防御

避免使用重定向和转发。
如果使用了重定向和转发，则不要在计算目标时涉及到用户参数(这通常容易做到)
如果使用目标参数无法避免,应确保其所提供的值对于当前用户是有效的,并已经授权。建议把这种目标的参数做成一个映射值，而不是真的URL或其中的一部分，然后由服务器端代码将映射值转换成目标URL。
设置白名单，验证forward的地址的合法性