常见Web漏洞的修复建议手册

漏洞类型	修复建议
明文传输	1、需要对密码字段进行md5+salt(aes/rsa等不可逆算法)加密
用户名枚举	1、建议对接口登录页面的判断回显信息修改为一致：用户名或密码错误(模糊提示)。
用户名暴力破解	1、账户锁定 账户锁定是很有效的方法，因为暴力破解程序在5-6次的探测中猜出密码的可能性很小。但是同时也拒绝了正常用户的使用。如果攻击者的探测是建立在用户名探测成功之后的行为，那么会造成严重的拒绝服务攻击。对于对大量用户名只用一个密码的探测攻击账户锁定无效。如果对已经锁定的账户并不返回任何信息，可能迷惑攻击者。 2、 返回信息 如果不管结果如何都返回成功的信息，破解软件就会停止攻击。但是对人来说很快就会被识破。 3、 页面跳转 产生登录错的的时候就跳到另一个页面要求重新登录。比如126和校内网都是这样做的。局限性在于不能总是跳转页面，一般只在第一次错误的时候跳转，但是第一次之后又可以继续暴力探测了。 4、 适当的延时 检查密码的时候适当的插入一些暂停，可以减缓攻击，但是可能对用户造成一定的影响。 5、 封锁多次登录的IP地址 这种方法也是有缺点的，因为攻击者可以定时更换自己的IP。 6、 验证码 验证码是阻止暴力攻击的好方法，但设计不好的验证码是可以绕过的，而且对于特定目标的手工探测来说验证码是没有作用的
短信验证码爆破	1、 短信验证码不少于6位； 2、有效期不超过1分钟； 3、 验证码错误次数超过上限应采取账户锁定策略。
验证码有效性	检验验证码是否生效
图形验证码绕过	1、 系统在开发时注意验证识别后销毁session中的验证码。 2、 限制用户提交的验证码不能为空。 3、 判断提交的验证码与服务器上存储的是否一致。 4、 禁止将验证码明文信息发送至客户端。
短信验证码绕过	1、若存在特权验证码，建议将其删除； 2 、应用服务端应严格校验验证码参数是否为空，格式是否正确；  3 、关键操作每提交一次请求，应发送新的短信验证码，并且不可继续使用旧的验证  4、短信验证码应该进行服务器端验证。
会话固定	1、在用户提供的认证信息（例如用户名和密码）、相应的权限级别发生变化时，服务器端应重新生成SessionID，并强制失效之前的会话，JAVA示例代码如下： request.getSession().invalidate();//清空session Cookie cookie = request.getCookies()[0];//获取cookie cookie.setMaxAge(0);//让cookie过期 。
会话重用	1、用户退出系统后，服务器端应清空此用户的Session信息
会话失效时间过长	1、 服务器端设置Session的存活时间，超过存活时间强制销毁Session。 2、 当客户端发生变化时（比如IP、UserAgent等信息），要求用户重新登录。 3、 限制每个用户只允许拥有一个有效Session，当用户再次登录时，攻击者所保持的Session便会失效。
Cookie中存在敏感信息	1、(屏蔽)删除cookie上面的敏感信息字段
报错页面敏感信息泄露	1、编码时增加异常处理模块，对错误页面做统一的自定义返回界面，隐藏服务器版本信息； 2、不对外输出程序运行时产生的异常错误信息详情。
SVN信息泄露	1、删除SVN各目录下的.svn目录，删除CVS的CVS目录，或者对URL中进行过滤，过滤相关svn等相关敏感字符
备份文件信息泄露	1、网站管理员严格检查web中可访问的路径下是否存在备份文件，常见备份文件后缀为.jsp.bak、.bak、.sql、.txt、等等。如果有这些文件，直接将该备份文件进行转移到其他目录或者直接删除即可。  2、严格控制可网站可访问目录下的文件敏感度的存放问题，不要将敏感文件置于该目录。
github信息泄露	1、及时删除github上面泄露的敏感信息  2、员工意识培训，禁止将公司文件上传到github。
目录浏览	目前存在该漏洞的常见中间件为apache和IIS,以下列出其相关的修复方式： 1、IIS中关闭目录浏览功能：在IIS的网站属性中，勾去“目录浏览”选项，重启IIS。 2、Apache中关闭目录浏览功能：打开Apache配置文件httpd.conf，查找“Options Indexes FollowSymLinks”，修改为“ Options -Indexes”(减号表示取消，保存退出，重启Apache。 3、Nginx中默认不会开启目录浏览功能，若您发现当前已开启该功能，可以编辑nginx.conf文件，删除如下两行：autoindex on;autoindex_exact_size on，重启Nginx。
物理路径信息泄露	1、报错信息中不对外输出网站物理路径等敏感信息。
敏感信息明文存储	1、将敏感信息加密后进行存储
任意文件上传	1、 最有效的，将文件上传目录直接设置为不可执行，对于Linux而言，撤销其目录的'x'权限；实际中很多大型网站的上传应用都会放置在独立的存储上作为静态文件处理，一是方便使用缓存加速降低能耗，二是杜绝了脚本执行的可能性； 2、 文件类型检查：建议使用白名单方式，结合MIME Type、后缀检查等方式（即只允许允许的文件类型进行上传. 3、 使用随机数改写文件名和文件路径，使得用户不能轻易访问自己上传的文件；
任意文件下载	1、 对用户传过来的文件名参数进行硬编码或统一编码，对文件类型进行白名单控制，对包含恶意字符或者空字符的参数进行拒绝。 2、文件路径保存至数据库，让用户提交文件对应ID下载文件。 3、用户下载文件之前需要进行权限判断。 4、文件放在web无法直接访问的目录下。 5、不允许提供目录遍历服务。 9、公开文件可放置在web应用程序下载目录中通过链接进行下载。
文件读取	1、过滤点、斜杠、反斜杠等特殊字符，使用户在url中不能回溯上级目录 2、文件命名为复杂名字，采用随机生成方式进行命名 3、控制文件访问权限
短信炸弹	1、合理配置短信接口，对于同一手机号码，发送次数不超过3-5次，并且对发送的时间间隔做限制。 2、页面前台代码编写时，加入禁止针对同一手机号进行的次数大于N次的发送，或者在页面中加入验证码功能，并且做时间间隔发送限制。
邮件炸弹	1、合理配置后台邮件接口，对于同一邮箱，发送次数不超过3-5次，并且可对发送的时间间隔做限制。 2、页面前台代码编写时，加入禁止针对同一手机号进行的次数大于N次的发送，或者在页面中加入验证码功能，并且做时间间隔发送限制。
越权	1、对该功能所有的查询接口进行权限控制。
未授权访问	1、对接口进行权限控制校验
CSRF漏洞	1. 通过referer判断页面来源进行CSRF防护，该方式无法防止站内CSRF攻击及referer字段伪造。 2. 重要功能点使用动态验证码进行CSRF防护。 3. 通过token方式进行CSRF防护 4. 为每个session创建唯一的随机字符串，并在受理请求时验证。
SQL注入	1. 对用户输入的特殊字符进行严格过滤，如’、”、<、>、/、*、;、+、-、&、|、(、)、and、or、select、union。 2. 使用参数化查询（PreparedStatement），避免将未经过滤的输入直接拼接到SQL查询语句中。 3. Web应用中用于连接数据库的用户与数据库的系统管理员用户的权限有严格的区分（如不能执行drop等），并设置Web应用中用于连接数据库的用户不允许操作其他数据库。 4. 设置Web应用中用于连接数据库的用户对Web目录不允许有写权限。
XSS	总体修复方式：验证所有输入数据，有效检测攻击；对所有输出数据进行适当的编码，以防止任何已成功注入的脚本在浏览器端运行。具体如下 ： 1、输入验证：某个数据被接受为可被显示或存储之前，使用标准输入验证机制，验证所有输入数据的长度、类型、语法以及业务规则。 2、输出编码：数据输出前，确保用户提交的数据已被正确进行entity编码，建议对所有字符进行编码而不仅局限于某个子集。 3、明确指定输出的编码方式：不要允许攻击者为你的用户选择编码方式(如ISO8859-1或 UTF 8)。 4、警惕规范化错误：验证输入之前，必须进行解码及规范化以符合应用程序当前的内部表示方法。请确定应用程序对同一输入不做两次解码。 对客户端提交的数据进行过滤，一般建议过滤掉双引号（”）、尖括号（<、>）等特殊字符，或者对客户端提交的数据中包含的特殊字符进行实体转换，如下所示 1、以下为需过滤的常见字符： [1] |（竖线符号） [2] & （& 符号） [3];（分号） [4] $（美元符号） [5] %（百分比符号） [6] @（at 符号） [7] '（单引号） [8] "（引号） [9] \'（反斜杠转义单引号） [10] \"（反斜杠转义引号） [11] <>（尖括号） [12] ()（括号） [13] +（加号） [14] CR（回车符，ASCII 0x0d） [15] LF（换行，ASCII 0x0a） [16] ,（逗号） [17] \（反斜杠） 5、在不影响应用的前提下，建议将cookie标记为httpOnly，同时禁用TRACE方法。 6、html实体编码
URL重定向	对传入的URL做有效性的认证，保证该URL来自于信任域。限制的方式可参考以下两种： 1. 限制Referer（Referer是HTTP header中的字段，当浏览器向web服务器发送请求时，一般会带上Referer，告诉服务器是从哪个页面链接过来的），通过限制Referer保证将要跳转URL的有效性，避免攻击者生成自己的恶意跳转链接； 2. 加入有效性验证Token，保证所有生成的链接都来自于可信域，通过在生成的链接里加入用户不可控的Token对生成的链接进行校验。
SSRF	1、过滤返回信息，验证远程服务器对请求的响应是比较容易的方法。如果web应用是去获取某一种类型的文件，那么在把返回结果展示给用户之前先验证返回的信息是否符合标准。 2、禁用不需要的协议，仅仅允许http和https请求。可以防止file/gopher/dict等协议引起的问题 3、设置URL白名单或者限制内网IP（使用gethostbyname()判断是否为内网IP） 4、限制请求的端口为http常用的端口，比如 80、443、8080、8090 5、统一配置错误信息，避免用户可以根据错误信息来判断远程服务器的端口状态。