白帽子讲Web安全——服务端安全

一.注入攻击

安全设计原则——“数据与代码分离”原则，它可以说是专门为了解决注入攻击而生的。

注入攻击的本质，是把用户输入的数据当做代码执行。这里有两个关键条件：

• 第一个是用户能够控制输入；
• 第二个是原本程序要执行的代码，拼接了用户输入的数据。

注入类型

• SQL注入
• XML注入
• 代码注入
• CRLF注入：CRLF常被用做不同语义之间的分隔符。因此通过“注入CRLF字符”，就有可能改变原有的语义。

攻击手段

• 攻击存储过程
• 命令执行：利用“用户自定义函数”的技巧，即UDF（User-Defined Functions）来执行命令。在建立数据库账户时应该遵循“最小权限原则”，尽量避免给Web应用使用数据库的管理员权限。
• 编码问题：要解决编码注入问题，需要统一数据库、操作系统、Web应用所使用的字符集，以避免各层对字符的理解存在差异。统一设置为UTF-8是一个很好的方法。
• SQL Column Truncation

防御手段

• 防御SQL注入的最佳方式，就是使用预编译语句，绑定变量。
• 尽量避免在存储过程内使用动态的SQL语句。
• 检查输入数据的数据类型，在很大程度上可以对抗SQL注入。
• 对抗代码注入、命令注入时，需要禁用eval()、system()等可以执行命令的函数。如果一定要使用这些函数，则需要对用户的输入数据进行处理。此外，在PHP/JSP中避免动态include远程文件，或者安全地处理它。
• 对抗CRLF的方法非常简单，只需要处理好“\r”、“\n”这两个保留字符即可，尤其是那些使用“换行符”作为分隔符的应用。

二.文件上传漏洞

文件上传漏洞是指用户上传了一个可执行的脚本文件，并通过此脚本文件获得了执行服务器端命令的能力。

文件上传后导致的常见安全问题一般有：

• 上传文件是Web脚本语言，服务器的Web容器解释并执行了用户上传的脚本，导致代码执行；
• 上传文件是Flash的策略文件crossdomain.xml，黑客用以控制Flash在该域下的行为（其他通过类似方式控制策略文件的情况类似）；
• 上传文件是病毒、木马文件，黑客用以诱骗用户或者管理员下载执行；
• 上传文件是钓鱼图片或为包含了脚本的图片，在某些版本的浏览器中会被作为脚本执行，被用于钓鱼和欺诈。

webshell

要完成webshell攻击，要满足如下几个条件：

1. 首先，上传的文件能够被Web容器解释执行。所以文件上传后所在的目录要是Web容器所覆盖到的路径。
2. 其次，用户能够从Web上访问这个文件。如果文件上传了，但用户无法通过Web访问，或者无法使得Web容器解释这个脚本，那么也不能称之为漏洞。
3. 最后，用户上传的文件若被安全检查、格式化、图片压缩等功能改变了内容，则也可能导致攻击不成功。

防御手段

• 文件上传的目录设置为不可执行；
• 判断文件类型；
• 使用随机数改写文件名和文件路径；
• 单独设置文件服务器的域名；

三.认证与会话管理

认证的目的是为了认出用户是谁，而授权的目的是为了决定用户能够做什么。

认证实际上就是一个验证凭证的过程。

1.密码认证

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

目前黑客们广泛使用的一种破解MD5后密码的方法是“彩虹表（Rainbow Table）”。

彩虹表的思路是收集尽可能多的密码明文和明文对应的MD5值。这样只需要查询MD5值，就能找到该MD5值对应的明文。

通过加盐可以有效对抗彩虹表。在计算密码明文的哈希值时，增加一个“Salt”。“Salt”是一个字符串，它的作用是为了增加明文的复杂度，并能使得彩虹表一类的攻击失效。

2.多因素认证

多因素认证提高了攻击的门槛。比如一个支付交易使用了密码与数字证书双因素认证，成功完成该交易必须满足两个条件：一是密码正确；二是进行支付的电脑必须安装了该用户的数字证书。因此，为了成功实施攻击，黑客们除了盗取用户密码外，还不得不想办法在用户电脑上完成支付，这样就大大提高了攻击的成本。

3.Session与认证

Session劫持就是一种通过窃取用户SessionID后，使用该SessionID登录进目标账户的攻击方法，此时攻击者实际上是使用了目标账户的有效Session。如果SessionID是保存在Cookie中的，则这种攻击可以称为Cookie劫持。

Cookie泄露的途径：

• XSS攻击：通过给Cookie标记httponly，可以有效地缓解XSS窃取Cookie的问题。
• 网络嗅探
• 本地木马窃取

4.Session Fixation攻击

在用户登录网站的过程中，如果登录前后用户的SessionID没有发生变化，则会存在Session Fixation问题。

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

X如何才能让Y使用这个SessionID呢？如果SessionID保存在Cookie中，比较难做到这一点。但若是SessionID保存在URL中，则X只需要诱使Y打开认证URL即可。

解决Session Fixation的正确做法是，在登录完成后，重写SessionID。

5.单点登录

目前互联网上最为开放和流行的单点登录系统是OpenID。

OpenID是一个开放的单点登录框架，它希望使用URI作为用户在互联网上的身份标识，每个用户（End User）将拥有一个唯一的URI。在用户登录网站（Relying Party）时，用户只需要提交他的OpenID（就是用户唯一的URI）以及OpenID的提供者（OpenID Provider），网站就会将用户重定向到OpenID的提供者进行认证，认证完成后再重定向回网站。

参考文档: 单点登录

四.访问控制(权限控制)

权限控制(访问控制)，抽象地说，都是某个主体（subject）对某个客体（object）需要实施某种操作（operation），而系统对这种操作的限制就是权限控制。

在一个安全系统中，确定主体的身份是“认证”解决的问题；而客体是一种资源，是主体发起的请求的对象。在主体对客体进行操作的过程中，系统控制主体不能“无限制”地对客体进行操作，这个过程就是“访问控制”。

在Web应用中，根据访问客体的不同，常见的访问控制可以分为

• 基于URL的访问控制
• 基于方法（method）的访问控制
• 基于数据的访问控制

1.垂直权限管理

访问控制实际上是建立用户与权限之间的对应关系，现在应用广泛的一种方法，就是“基于角色的访问控制（Role-Based Access Control）”，简称RBAC。

RBAC 事先会在系统中定义出不同的角色，不同的角色拥有不同的权限，一个角色实际上就是一个权限的集合。而系统的所有用户都会被分配到不同的角色中，一个用户可能拥有多个角色，角色之间有高低之分（权限高低）。在系统验证权限时，只需要验证用户所属的角色，然后就可以根据该角色所拥有的权限进行授权了。

在配置权限时，应当使用“最小权限原则”，并使用“默认拒绝”的策略，只对有需要的主体单独配置“允许”的策略。这在很多时候能够避免发生“越权访问”。

2.水平权限管理

在RBAC这种“基于角色的访问控制”模型下，系统只会验证用户A是否属于角色RoleX，而不会判断用户A是否能访问只属于用户B的数据DataB，因此，发生了越权访问。这种问题，我们就称之为“水平权限管理问题”。

相对于垂直权限管理来说，水平权限问题出在同一个角色上。系统只验证了能访问数据的角色，既没有对角色内的用户做细分，也没有对数据的子集做细分，因此缺乏一个用户到数据之间的对应关系。由于水平权限管理是系统缺乏一个数据级的访问控制所造成的，因此水平权限管理又可以称之为“基于数据的访问控制”。

现在数据级权限管理并没有很通用的解决方案，一般是具体问题具体解决。

• 一个简单的数据级访问控制，可以考虑使用“用户组（Group）”的概念。比如一个用户组的数据只属于该组内的成员，只有同一用户组的成员才能实现对这些数据的操作。
• 此外，还可以考虑实现一个规则引擎，将访问控制的规则写在配置文件中，通过规则引擎对数据的访问进行控制。

3.OAuth

OAuth是一个在不提供用户名和密码的情况下，授权第三方应用访问Web资源的安全协议。

常见的应用OAuth的场景，一般是某个网站想要获取一个用户在第三方网站中的某些资源或服务。

参考文档: OAuth 2.0

五.加密算法与随机数

常见的加密算法通常分为:

• 分组加密算法
• 流密码加密算法

1.加密算法

分组加密算法

分组加密算法基于“分组”（block）进行操作，根据算法的不同，每个分组的长度可能不同。分组加密算法的代表有DES、3-DES、Blowfish、IDEA、AES等。

(1) ECB模式

对于ECB模式来说，改变分组密文的顺序，将改变解密后的明文顺序；替换某个分组密文，解密后该对应分组的明文也会被替换，而其他分组不受影响。

当需要加密的明文多于一个分组的长度时，应该避免使用ECB模式。

(2) CBC模式

Padding Oracle Attack: 可以在不知道密钥的情况下，通过对padding bytes的尝试，还原明文，或者构造出任意明文的密文。

Padding Oracle Attack的关键在于攻击者能够获知解密的结果是否符合padding。在实现和使用CBC模式的分组加密算法时，注意这一点即可。

流密码加密算法

流密码加密算法，则每次只处理一个字节，密钥独立于消息之外，两者通过异或实现加密与解密。流密码加密算法的代表有RC4、ORYX、SEAL等。

流密码的攻击方式:

(1) Reused Key Attack

使用同一个密钥进行多次加解密会导致该问题，可以使用随机的初始化向量来解决，随机的初始化向量使得明文每次加密后的产生的密文都是不同的。

(2) Bit-flipping Attack

在密码学中，攻击者在不知道明文的情况下，通过改变密文，使得明文按其需要的方式发生改变的攻击方式，被称为 Bit-flipping Attack。

防御手段是验证密文的完整性，最常见的方法是增加带有KEY的MAC（消息验证码），通过MAC验证密文是否被篡改。

(3) WEP破解

WEP是一种常用的无线加密传输协议，破解了WEP的密钥，就可以以此连接无线的Access Point。

2.密钥管理

在密码学里有个基本的原则：密码系统的安全性应该依赖于密钥的复杂性，而不应该依赖于算法的保密性。

密钥管理中最常见的错误，就是将密钥硬编码在代码里。同样的，将加密密钥、签名的salt等“key”硬编码在代码中，是非常不好的习惯。

对于Web应用来说，常见的做法是将密钥（包括密码）保存在配置文件或者数据库中，在使用时由程序读出密钥并加载进内存。密钥所在的配置文件或数据库需要严格的控制访问权限，同时也要确保运维或DBA中具有访问权限的人越少越好。

一个比较安全的密钥管理系统，可以将所有的密钥（包括一些敏感配置文件）都集中保存在一个服务器（集群）上，并通过Web Service的方式提供获取密钥的API。每个Web应用在需要使用密钥时，通过带认证信息的API请求密钥管理系统，动态获取密钥。Web应用不能把密钥写入本地文件中，只加载到内存，这样动态获取密钥最大程度地保护了密钥的私密性。密钥集中管理，降低了系统对于密钥的耦合性，也有利于定期更换密钥。

3.伪随机数问题

伪随机数，是通过一些数学算法生成的随机数，并非真正的随机数。密码学上的安全伪随机数应该是不可压缩的。

对应的“真随机数”，则是通过一些物理系统生成的随机数，比如电压的波动、硬盘磁头读/写时的寻道时间、空中电磁波的噪声等。

在开发程序时，要切记：不要把时间函数当成随机数使用。

伪随机数是由数学算法实现的，它真正随机的地方在于“种子（seed）”。种子一旦确定后，再通过同一伪随机数算法计算出来的随机数，其值是固定的，多次计算所得值的顺序也是固定的。

我们需要谨记：在重要或敏感的系统中，一定要使用足够强壮的随机数生成算法。在Java中，可以使用java.security.SecureRandom。

从算法上还可以通过多个随机数的组合，以增加随机数的复杂性。比如通过给随机数使用MD5算法后，再连接一个随机字符，然后再使用MD5算法一次。这些方法，也将极大地增加攻击的难度。

4.最佳实践

在加密算法的选择和使用上，有以下最佳实践：

1. 不要使用ECB模式；
2. 不要使用流密码（比如RC4）；
3. 使用HMAC-SHA1代替MD5（甚至是代替SHA1）；
4. 不要使用相同的key做不同的事情；
5. salts与IV需要随机产生；
6. 不要自己实现加密算法，尽量使用安全专家已经实现好的库；
7. 不要依赖系统的保密性。

当你不知道该如何选择时，有以下建议：

1. 使用CBC模式的AES256用于加密；
2. 使用HMAC-SHA512用于完整性检查；
3. 使用带salt的SHA-256或SHA-512用于Hashing。

六.Web框架安全

XSS

XSS攻击是在用户的浏览器上执行的，其形成过程则是在服务器端页面渲染时，注入了恶意的HTML代码导致的。从MVC架构来说，是发生在View层，因此使用“输出编码”的防御方法更加合理，这意味着需要针对不同上下文的XSS攻击场景，使用不同的编码方式。

“输出编码”的防御方法总结为以下几种：

• 在HTML标签中输出变量；
• 在HTML属性中输出变量；
• 在script标签中输出变量；
• 在事件中输出变量；
• 在CSS中输出变量；
• 在URL中输出变量。

针对不同的情况，使用不同的编码函数。

CSRF防御

完整的CSRF防御方案，对于Web框架来说有以下几处地方需要改动。

（1）在Session中绑定token。如果不能保存到服务器端Session中，则可以替代为保存到Cookie里。

（2）在form表单中自动填入token字段，比如 <input type=hidden name=“anti_csrf_token"value=”$token" />。

（3）在Ajax请求中自动添加token，这可能需要已有的Ajax封装实现的支持。

（4）在服务器端对比POST提交参数的token与Session中绑定的token是否一致，以验证CSRF攻击。

HTTP Headers管理

1.防御CRLF注入

对抗CRLF的方案只需要在“value”中编码所有的\r\n即可。

2.Location跳转

对于框架来说，管理好跳转目的地址是很有必要的。一般来说，可以在两个地方做这件事情：

（1）如果Web框架提供统一的跳转函数，则可以在跳转函数内部实现一个白名单，指定跳转地址只能在白名单中；

（2）另一种解决方式是控制HTTP的Location字段，限制Location的值只能是哪些地址，也能起到同样的效果，其本质还是白名单。

3.防御ClickJacking

对抗ClickJacking的X-Frame-Options，需要在页面的HTTP Response中添加。

该HTTP头有三个可选的值：SAMEORIGIN、DENY、ALLOW-FROM origin，适用于各种不同的场景。

4.防御Session劫持

一般来说，框架会提供一个统一的设置Cookie函数，HttpOnly的功能可以在此函数中实现；如果没有这样的函数，则需要统一在HTTP返回头中配置实现。

SQL注入

对抗SQL注入的最佳方式就是使用“预编译绑定变量”。

其他事项

文件上传：在web框架中提供统一的安全文件上传功能。

Spring Security为Spring MVC的用户提供了许多安全功能，比如基于URL的访问控制、加密方法、证书支持、OpenID支持等。但Spring Security尚缺乏诸如XSS、CSRF等问题的解决方案。

在设计Web框架安全解决方案时，还需要保存好安全检查的日志。

七.应用层拒绝服务攻击

DDOS简介

DDOS又称为分布式拒绝服务，全称是Distributed Denial of Service。DDOS本是利用合理的请求造成资源过载，导致服务不可用。

常见的DDOS攻击有SYN flood、UDP flood、ICMP flood等。

SYN flood在攻击时，首先伪造大量的源IP地址，分别向服务器端发送大量的SYN包，此时服务器端会返回SYN/ACK包，因为源地址是伪造的，所以伪造的IP并不会应答，服务器端没有收到伪造IP的回应，会重试3～5次并且等待一个SYN Time（一般为30秒至2分钟），如果超时则丢弃这个连接。攻击者大量发送这种伪造源地址的SYN请求，服务器端将会消耗非常多的资源（CPU和内存）来处理这种半连接，同时还要不断地对这些IP进行SYN+ACK重试。最后的结果是服务器无暇理睬正常的连接请求，导致拒绝服务。

对抗SYN flood的主要措施有SYN Cookie/SYN Proxy、safereset等算法。SYN Cookie的主要思想是为每一个IP地址分配一个“Cookie”，并统计每个IP地址的访问频率。如果在短时间内收到大量的来自同一个IP地址的数据包，则认为受到攻击，之后来自这个IP地址的包将被丢弃。

但DDOS仍然是业界的一个难题，当攻击流量超过了网络设备，甚至带宽的最大负荷时，网络仍将瘫痪。

应用层DDOS

1.CC攻击

CC攻击的原理非常简单，就是对一些消耗资源较大的应用页面不断发起正常的请求，以达到消耗服务端资源的目的。在Web应用中，查询数据库、读/写硬盘文件等操作，相对都会消耗比较多的资源。

最常见的针对应用层DDOS攻击的防御措施，是在应用中针对每个“客户端”做一个请求频率的限制。

在实际的攻击中，大量使用代理服务器或傀儡机来隐藏攻击者的真实IP地址，已经成为一种成熟的攻击模式。攻击者使用这些方法可不断地变换IP地址，就可以绕过服务器对单个IP地址请求频率的限制了。

常用防御手段：

• 首先，应用代码要做好性能优化。合理地使用memcache就是一个很好的优化方案，将数据库的压力尽可能转移到内存中。此外还需要及时地释放资源，比如及时关闭数据库连接，减少空连接等消耗。
• 其次，在网络架构上做好优化。善于利用负载均衡分流，避免用户流量集中在单台服务器上。同时可以充分利用好CDN和镜像站点的分流作用，缓解主站的压力。
• 最后，也是最重要的一点，实现一些对抗手段，比如限制每个IP地址的请求频率。

2.验证码

验证码用于识别人和机器，可以有效阻止自动化的重放行为。

验证码的验证过程，是比对用户提交的明文和服务器端Session里保存的验证码明文是否一致。所以曾经有验证码系统出现过这样的漏洞：因为验证码消耗掉后SessionID未更新，导致使用原有的SessionID可以一直重复提交同一个验证码。

3.防御应用层DDOS

在面对单个IP地址或者IP地址较少的情况下，可以限制IP访问频率。

如果攻击者使用了代理服务器、傀儡机进行攻击，Yahoo为我们提供了一个解决思路。因为发起应用层DDOS攻击的IP地址都是真实的，所以在实际情况中，攻击者的IP地址其实也不可能无限制增长。假设攻击者有1000个IP地址发起攻击，如果请求了10000次，则平均每个IP地址请求同一页面达到10次，攻击如果持续下去，单个IP地址的请求也将变多，但无论如何变，都是在这1000个IP地址的范围内做轮询。

为此Yahoo实现了一套算法，根据IP地址和Cookie等信息，可以计算客户端的请求频率并进行拦截。Yahoo设计的这套系统也是为Web Server开发的一个模块，但在整体架构上会有一台master服务器集中计算所有IP地址的请求频率，并同步策略到每台WebServer上。

资源耗尽攻击

1.SIowIoris攻击

原理是以极低的速度往服务器发送HTTP请求。由于Web Server对于并发的连接数都有一定的上限，因此若是恶意地占用住这些连接不释放，那么Web Server的所有连接都将被恶意连接占用，从而无法接受新的请求，导致拒绝服务。

此类拒绝服务攻击的本质，实际上是对有限资源的无限制滥用。

2.HTTP POST DOS

原理是在发送HTTP POST包时，指定一个非常大的Content-Length值，然后以很低的速度发包，比如10～100s发一个字节，保持住这个连接不断开。这样当客户端连接数多了以后，占用住了Web Server的所有可用连接，从而导致DOS。

出于可用性和物理条件的限制，内存、进程数、存储空间等资源都不可能无限制地增长，因此如果未对不可信任的资源使用者进行配额的限制，就有可能造成拒绝服务。内存泄漏是程序员经常需要解决的一种bug，而在安全领域中，内存泄漏则被认为是一种能够造成拒绝服务攻击的方式。

3.Server Limit DOS

Web Server对HTTP头部都有长度限制，如果客户端发送的HTTP包头超过这个大小，服务器就会返回一个4xx错误。

假如攻击者通过XSS攻击，恶意地往客户端写入了一个超长的Cookie，则该客户端在清空Cookie之前，将无法再访问该Cookie所在域的任何页面。这是因为Cookie也是放在HTTP包头里发送的，而Web Server默认会认为这是一个超长的非正常请求，从而导致“客户端”的拒绝服务。

ReDOS

当正则表达式写得不好时，就有可能被恶意输入利用，消耗大量资源，从而造成DOS。这种攻击被称为ReDOS。

正则表达式是基于NFA（Nondeterministic Finite Automaton）的，它是一个状态机，每个状态和输入符号都可能有许多不同的下一个状态。正则解析引擎将遍历所有可能的路径直到最后。由于每个状态都有若干个“下一个状态”，因此决策算法将逐个尝试每个“下一个状态”，直到找到一个匹配的。

当用户恶意构造输入时，有缺陷的正则表达式需要遍历大量路径，消耗大量的系统资源（比如CPU和内存），从而导致整台服务器的性能下降，表现的结果是系统速度很慢，有的进程或服务失去响应，与拒绝服务的后果是一样的。

Web Server配置安全

Web服务器安全，考虑的是应用布署时的运行环境安全。这个运行环境包括Web Server、脚本语言解释器、中间件等软件，这些软件所提供的一些配置参数，也可以起到安全保护的作用。

1.Apache Httpd安全

Apache有很多官方与非官方的Module，默认启动的Module出现过的高危漏洞非常少，大多数的高危漏洞集中在默认没有安装或enable的Module上。

因此，检查Apache安全的第一件事情，就是检查Apache的Module安装情况，根据“最小权限原则”，应该尽可能地减少不必要的Module，对于要使用的Module，则检查其对应版本是否存在已知的安全漏洞。

定制好了Apache的安装包后，接下来需要做的，就是指定Apache进程以单独的用户身份运行，这通常需要为Apache单独建立一个user/group。需要注意的是，Apache以root身份或者admin身份运行是一个非常糟糕的决定。

使用高权限身份运行Apache的结果可能是灾难性的，它会带来两个可怕的后果：

1. 当黑客入侵Web成功时，将直接获得一个高权限（比如root或admin）的shell；
2. 应用程序本身将具备较高权限，当出现bug时，可能会带来较高风险，比如删除本地重要文件、杀死进程等不可预知的结果。

最后，要保护好Apache Log。一般来说，攻击者入侵成功后，要做的第一件事情就是清除入侵痕迹，修改、删除日志文件，因此access log应当妥善保管，比如实时地发送到远程的syslog服务器上。

Apache还提供了一些配置参数，可以用来优化服务器的性能，提高对抗DDOS攻击的能力。

• TimeOut
• KeepAlive
• LimitRequestBody
• LimitRequestFields
• LimitRequestFieldSize
• LimitRequestLine
• LimitXMLRequestBody
• AcceptFilter
• MaxRequestWorkers

2.Nginx安全

就软件安全本身来看，Nginx与Apache最大的区别在于，检查Apache安全时更多的要关注Module的安全，而Nginx则需要注意软件本身的安全，及时升级软件版本。

与Apache一样，Nginx也应该以单独的身份运行，这是所有Web Server、容器软件应该共同遵守的原则。

Nginx的配置非常灵活，在对抗DDOS和CC攻击方面也能起到一定的缓解作用，比如下面的一些配置参数：

worker_processes 1;
worker_rlimit_nofile 80000;
events {
    worker_connections 50000;
}

server_tokens off;
log_format IP `$remote_addr';
reset_timedout_connection on;

listen  xx.xx.xx.xx:80  
default rcvbuf=8192 sndbuf=16384 backlog=32000
accept_filter=httpready;

其次，在Nginx配置中还可以做一些简单的条件判断，比如客户端User-Agent具有什么特征，或者来自某个特定referer、IP等条件，响应动作可以是返回错误号，或进行重定向。

Web Server对于DDOS攻击的防御作用是有限的。对于大规模的拒绝服务攻击，需要使用更加专业的保护方案。

3.jBoss远程命令执行

jBoss是J2EE环境中一个流行的Web容器，但是jBoss在默认安装时提供的一些功能却不太安全，如果配置不得当，则可能直接造成远程命令执行。

由于jBoss在默认安装时会有一个管理后台，叫做JMX-Console，它提供给管理员一些强大的功能，其中包括配置MBeans，这同样也会为黑客们打开方便之门。通过8080端口（默认安装时会监听8080端口）访问 /jmx-console能够进入到这个管理界面。默认安装时访问JMX-Console是没有任何认证的。

在JMX-Console中，有多种可以远程执行命令的方法。

• 最简单的方式，是通过DeploymentScanner远程加载一个war包。
• 通过JMX-Console提供的BSH（Bean Shell）Deployment方法，同样也能布署war包。BSH能够执行一次性的脚本，或者创建服务，这对于黑客来说很有用。

因此出于安全防御的目的，在加固时，需要删除JMX-Console后台，事实上，jBoss的使用完全可以不依赖于它。

如果出于业务需要不得不使用JMX-Console，则应该使用一个强壮的密码，并且运行JMX-Console的端口不应该面向整个Internet开放。

4.Tomcat远程命令执行

虽然Tomcat后台有密码认证，但强烈建议删除这一后台，因为攻击者可以通过暴力破解等方式获取后台的访问权限，从安全的角度看，这增加了系统的攻击面，得不偿失。

5.HTTP Parameter Pollution

通过GET或POST向服务器发起请求时，提交两个相同的参数，那么服务器会如何选择呢？

在某些服务端环境中，会只取第一个参数；而在另外一些环境中，比如．net环境中，则会变成：

a=test, test1

这种特性在绕过一些服务器端的逻辑判断时，会非常有用。