黑客技术：一个“登录框”引发的安全问题

前言

搞安全的小伙伴只有一个登录框你都能测试哪些漏洞？

通常大家测试的都会测试关键部分，为了有更好的测试效果，小厂会提供给你用户名密码；但是一些比较重要的企业，而这个环境却是正式环境，里面存放着一些数据不希望被你看到的时候，是不会提供给给你登录账号的。这个时候，考验你基础知识是否扎实的时刻来临了。

用户名枚举

漏洞描述：

存在于系统登录页面，利用登陆时输入系统存在的用户名错误密码和不存在的用户名错误密码，返回不同的出错信息可枚举出系统中存在的账号信息。

测试方法：

找到网站或者web系统登录页面。在web系统登录页面，通过手工方式，利用系统中存在的用户名和不存在的用户名，密码随意，尝试登录，查看其回显内容。例如：输入存在的用户名admin，回显如下：密码错误；输入不存在的用户名test，回显如下：用户不存在。

示例：

风险分析：

攻击者根据Web应用程序返回的上述提示信息即可枚举系统中存在的登录用户名，然后针对枚举出来的登录用户名，对其密码进行暴力破解。

修复方案：

建议对网站登录页面的判断回显信息修改为一致：用户名或密码错误。

弱口令

漏洞描述：

认证登录环节存在弱口令

测试方法：

1.找到网站登录页面，尝试输入常见弱口令；

2.根据网站所使用的第三方组件，寻找特定的弱口令或默认口令进行登录。

示例：

通常很多厂商后台默认账户为“admin”，密码为"admin"或“123456”，大家可以通过暴力破解去尝试

风险分析：

攻击者可利用互联网公开的常见弱口令尝试登录管理后台，对网站造成一定的影响。

修复方案：

禁止使用弱口令，口令应满足一定的复杂度。

空口令

漏洞描述：

认证登录环节允许空口令

测试方法：

找到网站登录页面，尝试输入用用户名，密码为空进行登录。
示例：暂无

风险分析：

攻击者可利用该漏洞登录网站后台，操作敏感数据，甚至上传webshell，从而控制服务器。

修复方案：

判断输入密码是否为空，禁止空口令登录。

登录认证绕过

漏洞描述：

能够绕过应用认证，直接登录系统。

测试方法：

绕过认证主要有几下几种途径：

1.网络嗅探。通过网络嗅探工具探测局域网中传输的明文用户名和密码。有些应用程序采用GET方式发送登录请求，可能导致GET的URL请求内容被缓存在代理服务器活着Web服务器端，导致用户名和密码泄漏。

2.默认或可猜测的用户账号。大多数开源软件或商业软件提供的基于网络配置和管理的接口，通常都会有一些默认的用户名和密码。例如，一般默认的用户名是：admin，administrator、root、system、guest等，而默认的秘密吗也根据硬件和软件的不同而不同，可尝试一下这些密码：password、admin、guest、12345等。

3.直接访问内部URL。使用Spider工具找到含有admin、manager、administrator、login等词语的路径，尝试使用普通的登录用户访问这些URL。从而获得管理员的权限。

4.修改参数绕过认证。应用程序可能会会使用一个参数或一个隐藏的域表示一个用户是否经过验证了，通过修改这些参数，从而被认为是已经认证过的用户。例如：http://www.xxx.xom/userinfo.jsp?authenticated=no，通过修改authenticated参数为yes，http://www.xxx.xom/userinfo.jsp?authenticated=yes，然后就可以通过认证，直接访问内部页面。

5.可猜测的SessionID。利用规律，猜测到一个有效的SessionID，然后通过修改请求中的SessionID为一个预测到的有效的SessionID，从而冒充会话的真正拥有着，绕过认证环节。

6.注入问题。利用万能密码登录系统，绕过认证环节。

7.CSRF。利用CSRF漏洞在用户不知情的情况下，利用用户的会话进行敏感操作，从而绕过认证。

示例：

Apache shiro cve-2020-17523 Apache shiro较新的登录认证绕过，大概的方式就是使用空字符绕过
www.xxx.com/admin/%20/
www.xxx.com/admin/%2e/
示例用户名密码可以乱写

点击登陆按钮同时使用抓包工具进行数据包拦截

将数据包返回至当前页面，修改code值
登录成功

风险分析：

如果应用程序在认证上没有做好，可以导致恶意用户或者攻击者绕过认证，访问内部资源，这类漏洞通过防火墙和入侵检测系统很难预防。

修复方案：

可从以下几个方面预防认证绕过：

1.对于每一个访问的URL都首先检查是否已经登录（不需要认证的URL除外，例如，帮助页面、免费下载页面等），如果没有登录，则跳转到登录页面。对于已经登录的用户，在退出的时候或者在会话很长时间处于idle状态的时候，需要保证原来的会话被正确的销毁并且不会再被重利用。

2.规定密码强度要求，防止密码被猜测到。

3.对于用户是否已经认证，禁止依赖客户端传过来的参数标识，而应将是否登录的标识保存在服务器端的会话中，当接收到该会话的请求时，从会话保存的状态判断是否登录。

4.对于SessionID一定要使用安全的随机数生成算法，使得SessionID不可预测。

5.对于暴力破解攻击，建议在尝试3次左右失败之后，使用图形验证码。

存在暴力破解

漏洞描述：

暴力破解的基本思想是根据题目的部分条件确定答案的大致范围，并在此范围内对所有可能的情况逐一验证，直到全部情况验证完毕。若某个情况验证符合题目的全部条件，则为本问题的一个解；若全部情况验证后都不符合题目的全部条件，则本题无解。常常存在于网站的登录系统中，通过对已知的管理员用户名，进行对其登录口令的大量尝试。

测试方法：

找到网站登录页面。

利用burp对登录页面进行抓包，将其发送到Intruder,并设置其密码参数，如pwd=为变量，添加payload（字典），进行攻击，攻击过程中查看其返回的字节长度，来判断是否成功。

一般情况下，暴力破解有三种形式：

固定账号对密码暴力破解。

在得知账号具有规律性，或者通过某种方式获取到大量账号的前提下，固定密码对账号暴力破解。

使用网上流传的账号密码库进行撞库攻击。

示例：

风险分析：

攻击者一般会使用自动化脚本组合出常见的用户名和密码，即字典，再结合软件burpsuite的intruder功能进行暴力破解。

修复方案：

防止暴力攻击的一些方法如下：

1、账户锁定

账户锁定是很有效的方法，因为暴力破解程序在5-6次的探测中猜出密码的可能性很小。但是同时也拒绝了正常用户的使用。如果攻击者的探测是建立在用户名探测成功之后的行为，那么会造成严重的拒绝服务攻击。对于对大量用户名只用一个密码的探测攻击账户锁定无效。如果对已经锁定的账户并不返回任何信息，可能迷惑攻击者。

2、返回信息

如果不管结果如何都返回成功的信息，破解软件就会停止攻击。但是对人来说很快就会被识破。

3、页面跳转

产生登录错的的时候就跳到另一个页面要求重新登录。比如126和校内网都是这样做的。局限性在于不能总是跳转页面，一般只在第一次错误的时候跳转，但是第一次之后又可以继续暴力探测了。

4、适当的延时

检查密码的时候适当的插入一些暂停，可以减缓攻击，但是可能对用户造成一定的影响。

5、封锁多次登录的IP地址

这种方法也是有缺点的，因为攻击者可以定时更换自己的IP。

6、验证码

验证码是阻止暴力攻击的好方法，但设计不好的验证码是可以绕过的，而且对于特定目标的手工探测来说验证码是没有作用的。

图形验证码不失效

漏洞描述：

有些网站登录框存在图形验证码，防止暴力破解攻击，但是正常的逻辑是前端输入验证码之后进行校验图形验证码的正确性，而后若是为真则进行登录操作，为假则返回验证码输入错误，而使用一次的验证码应该立即失效。然而有些网站验证码可能是可控的，输入一些特殊字符可能就能打到欺骗服务器或验证码使用一次之后并没有及时刷新（所谓的验证码可以被自动识别这个问题，我个人觉得没啥卵用，就不写了）

测试方法：

输入用户名、密码、验证码后，点击登陆按钮同时将数据包使用burpsuite进行拦截，并使用Repeater模块或Intruder模块进行数据重放，重新发送五次观察页面变化，是否会提示验证码输入错误等信息
示例：

此登录功能时存在图形验证码的，在输入了正确的图形验证码之后进行数据重放，发现图形验证码没有做到及时失效

风险分析：

图形验证码一般是防止使用程序恶意注册、暴力破解用户名密码或者批量发帖而设置的。在页面初始化时服务器向页面发送一个随机字符串，同时在Session里也保存一份，当用户提交时将随机数一起post到后台，通过与Session中保存的值对比，如果不相同，则有可能是恶意攻击。

修复方案：

1、系统在开发时注意验证识别后销毁session中的验证码。

2、限制用户提交的验证码不能为空

3、判断提交的验证码与服务器上存储的是否一致

4、禁止将验证码明文信息发送至客户端

短信验证码绕过

漏洞描述：

一些网站使用手机短信登录，短信验证码可被绕过，执行其他操作。

测试方法：

1.请求发送短信，填写任意验证码，然后提交其他操作请求，将验证码参数置空或删除，测试是否可绕过检测；

2.尝试特权验证码，如000000、111111等；

3.同一个短信验证码是否能使用多次；

示例：

正确的逻辑应当是，短信验证码获取后，服务器校验短信验证码的来源以及有效性，使用一次后应该立即失效。但是我遇到的这个就是使用验证码登录后，注销用户登录后再一次使用验证码发现依然登陆成功，也就是短信验证码没有被删除

风险分析：

修改／重置密码、交易操作等功能通常需要短信验证码，若验证码可绕过，攻击者可利用该漏洞进行重置他人密码或转账等危险操作。

修复方案：

1.若存在特权验证码，建议将其删除；

2.应用服务端应严格校验验证码参数是否为空，格式是否正确；

3.关键操作每提交一次请求，应发送新的短信验证码，并且不可继续使用旧的验证码。

短信验证码可暴力破解

漏洞描述：

短信验证码位数太短或有效期太长导致可暴力破解

测试方法：

点击发送短信验证码，输入任意验证码，提交请求，使用burpsuite拦截请求，在intruder模块设置验证码参数为枚举变量，这是payload类型为numbers，对验证码进行暴力破解。

示例：

这里的短信验证码可被暴力破解，是因为并没有设置短信验证码使用错误几次后失效，故可被暴力破解

风险分析：

修改／重置密码、交易操作等功能通常需要短信验证码，若验证码可暴力破解，攻击者可利用该漏洞进行重置他人密码或转账等危险操作。

修复方案：

1.短信验证码不少于6位；

2.有效期不超过1分钟；

3.验证码错误次数超过上限应采取账户锁定策略。

短信攻击

漏洞描述：

短信攻击时常见的一种攻击，攻击者通过网站页面中所提供的发送短信验证码的功能处，通过对其发送数据包的获取后，进行重放，如果服务器短信平台未做校验的情况时，系统会一直去发送短信，这样就造成了短信轰炸的漏洞。

测试方法：

1、手工找到有关网站注册页面，认证页面，是否具有短信发送页面，如果有，则进行下一步。

2、通过利用burp或者其它抓包截断工具，抓取发送验证码的数据包，并且进行重放攻击，查看手机是否在短时间内连续收到10条以上短信，如果收到大量短信，则说明存在该漏洞。

示例：

点击获取验证码同时拦截数据包

使用burpsuite进行数据重放

风险分析：

攻击者通过填写他人的手机号，使用软件burpsuite的intruder功能重复提交发送短信的请求包，达到短时间内向他人的手机上发送大量垃圾短信的目的。

修复方案：

1、合理配置后台短信服务器的功能，对于同一手机号码，发送次数不超过3-5次，并且可对发送的时间间隔做限制。

2、页面前台代码编写时，加入禁止针对同一手机号进行的次数大于N次的发送，或者在页面中加入验证码功能，并且限制发送的时间间隔。

恶意锁定问题

漏洞描述：

通过不断的输入错误的密码可恶意锁定任意账号

测试方法：

针对测试账户，不断输入错误的密码，直至将其锁定

示例：

风险分析：

若系统认证功能无防自动化处理模块，攻击者可编写脚本批量锁定系统账号。

修复方案：

1.账户锁定之后应不能继续使用认证功能

2.认证功能防自动化操作，如添加图形验证码。

密码明文传输

漏洞描述：

认证过程中传输未加密（用户名密码等敏感数据明文传输）。

测试方法：

通过对网站登录页面的请求进行抓包，工具可用burp、wireshark、filder、等等，分析其数据包中相关password（密码）参数的值是否为明文。如图利用wireshark抓包分析的密码：

示例：

1.输入用户名密码

2. 使用burpsuite进行数据包拦截

风险分析：

攻击者通过在局域网中嗅探网络流量，获取明文传输的认证凭证，如用户名密码、SESSIONID等敏感信息。

修复方案：

建议按照网站的密级要求，需要对密码传输过程中进行加密得使用加密的方式传输，如使用HTTPS， 但加密的方式增加成本，或许会影响用户体验。如果不用 HTTPS，可以在网站前端用 Javascript 做密码加密，加密后再进行传输。

反射型跨站脚本攻击

漏洞描述：

跨站脚本攻击的英文全称是Cross Site Script，为了和样式表区分，缩写为XSS。发生的原因是网站将用户输入的内容输出到页面上，在这个过程中可能有恶意代码被浏览器执行。跨站脚本攻击,它指的是恶意攻击者往Web页面里插入恶意html代码，当用户浏览该页之时，嵌入其中Web里面的html代码会被执行，从而达到恶意用户的特殊目的。已知的跨站脚本攻击漏洞有三种：1）存储式；2）反射式；3）基于DOM。

测试方法：

1、GET方式跨站脚本：

在输入的参数后逐条添加以下语句，以第一条为例，输入http://www.exmaple.com/page.xxx?name=
文本输入框：需要对页面上所有可以提交参数的地方进行测试。具体跨站脚本的测试语句根据实际情况的不同而不同，可自行构造，以及触发事件等切换，这里只列出了一些最常见构造语句。

示例：登录窗口用户名处存在反射型XSS注入
点击登陆，成功弹出内容

风险分析：

攻击者可以使用该漏洞构造钓鱼链接，诱骗受害者访问并填写用户名和密码，从而窃取用户的认证凭据

修复方案：

1、总体修复方式：验证所有输入数据，有效检测攻击；对所有输出数据进行适当的编码，以防止任何已成功注入的脚本在浏览器端运行。具体如下 ：

2、输入验证：某个数据被接受为可被显示或存储之前，使用标准输入验证机制，验证所有输入数据的长度、类型、语法以及业务规则。

3、输出编码：数据输出前，确保用户提交的数据已被正确进行entity编码，建议对所有字符进行编码而不仅局限于某个子集。

4、明确指定输出的编码方式：不要允许攻击者为你的用户选择编码方式(如ISO 8859-1或 UTF 8)。

5、注意黑名单验证方式的局限性：仅仅查找或替换一些字符(如"<" ">“或类似"script"的关键字)，很容易被XSS变种攻击绕过验证机制。

警惕规范化错误：验证输入之前，必须进行解码及规范化以符合应用程序当前的内部表示方法。请确定应用程序对同一输入不做两次解码。对客户端提交的数据进行过滤，一般建议过滤掉双引号（”）、尖括号（<、>）等特殊字符，或者对客户端提交的数据中包含的特殊字符进行实体转换，比如将双引号（”）转换成其实体形式”，<对应的实体形式是<，<对应的实体形式是>以下为需过滤的常见字符

万能密码

漏洞描述：

其实我觉得万能密码和sql注入应当区分开来，所以我就分开写了。
众所周知，登录处是一条查询操作，一些程序可能是没有注意到，就写成了

$result=mysqli_query($link,'select * from user');        #执行$sql命令,查询user列表行内容 $row=mysqli_fetch_assoc($result);       #解析，通过用户名判断 里面行的内容密码是否正确 if ( $username===$row['username'] && $password === $row['password']) {     echo '登陆成功';  $_SESSION['uid'] = $row['id'] ;     header("Location:3.php?id=".$row['id']);  } else{     echo '请重新填写账户或密码';

这个时候就可以构造特殊的sql语句进行截断，造成永真，这样的话就可以越过查询完成登录

测试方法：

(1)用户名输入： ‘ or 1=1 or ‘ 密码：任意

(2)Admin’ - -（或‘ or 1=1 or ‘ - -）(admin or 1=1 --) (MS SQL)(直接输入用户名，不进行密码验证)

(3)用户名输入：admin 密码输入：’ or ‘1’=’1 也可以

(4) 用户名输入：admin’ or ‘a’=‘a 密码输入：任意

(5) 用户名输入：‘ or 1=1 - -

(6) 用户名输入：admin‘ or 1=1 - - 密码输入：任意

(7) 用户名输入：1’or’1’=‘1’or’1’='1 密码输入：任意

示例：

这里的案例与上述的不太相同，他的查询多了一个判断动作，就是先判断用户名是否存在，存在的 时候才会进行下一步判断，判断用户名密码是否匹配，所以这里必须输入正确的用户名才行
admin’ or 1 #
点击登陆，成功登录

风险分析：

攻击者可通过万能密码直接登录后台，获取后台权限

修复方案：

1)对用户输入的特殊字符进行严格过滤，如’、”、<、>、/、*、;、+、-、&、|、(、)、and、or、select、union。

2)使用参数化查询（PreparedStatement），避免将未经过滤的输入直接拼接到SQL查询语句中。

3)Web应用中用于连接数据库的用户与数据库的系统管理员用户的权限有严格的区分（如不能执行drop等），并设置Web应用中用于连接数据库的用户不允许操作其他数据库。

4)设置Web应用中用于连接数据库的用户对Web目录不允许有写权限。

5)使用Web应用防火墙。

sql注入

漏洞描述：

所谓SQL注入，就是通过把SQL命令插入到Web表单提交或输入域名或页面请求的查询字符串，最终达到欺骗服务器执行恶意的SQL命令。具体来说，它是利用现有应用程序，将（恶意）SQL命令注入到后台数据库引擎执行的能力，它可以通过在Web表单中输入（恶意）SQL语句得到一个存在安全漏洞的网站上的数据库，而不是按照设计者意图去执行SQL语句。 造成SQL注入漏洞原因有两个：一个是没有对输入的数据进行过滤（过滤输入），还有一个是没有对发送到数据库的数据进行转义（转义输出）。

测试方法：

1.通过web漏洞扫描工具进行对网站爬虫后得到的所有链接进行检测，或者手工判断是否存在注入点，一旦确认存在漏洞，可利用自动化工具sqlmap去尝试注入。几种常见的判断方法：

1)数字型。
http://host/test.php?id=100 and 1=1 返回成功
http://host/test.php?id=100 and 1=2 返回失败

2)字符型。
http://host/test.php?name=rainman ’ and ‘1’=‘1 返回成功
http://host/test.php?name=rainman ’ and ‘1’=‘2 返回失败

3)搜索型。
搜索型注入：简单的判断搜索型注入漏洞是否存在的办法是：
先搜索（’），如果出错，说明90%存在这个漏洞。
然后搜索（%），如果正常返回，说明95%有洞了。
然后再搜索一个关键字，比如（2006）吧，正常返回所有2006相关的信息。
再搜索（2006%‘and 1=1 and ‘%’=’）和（2006%‘and 1=2 and ‘%’=’）

不同的SQL服务器连结字符串的语法不同，比如MS SQL Server使用符号+来连结字符串，而Oracle使用符号||来连结：

http://host/test.jsp?ProdName=Book’ 返回错误
http://host/test.jsp?ProdName=B’+’ook 返回正常
http://host/test.jsp?ProdName=B’||’ook 返回正常说明有SQL注入

2.如果应用程序已经过滤了’和+等特殊字符，我们仍然可以在输入时过把字符转换成URL编码（即字符ASCII码的16进制）来绕过检查。

示例：暂无

此处常常伴随着万能密码漏洞，故不做展示
风险分析：在输入URL和表单处，攻击者通过输入精心构造的SQL语句，对数据库记录进行增删改查，或直接获取服务器权限。攻击者实施SQL注入攻击时大多借助自动化注入工具，如穿山甲、明小子、sqlmap、Havij等。

修复方案：

SQL注入的主要原因是程序没有严格过滤用户输入的数据，导致非法数据侵入系统。

1)对用户输入的特殊字符进行严格过滤，如’、”、<、>、/、*、;、+、-、&、|、(、)、and、or、select、union。

2)使用参数化查询（PreparedStatement），避免将未经过滤的输入直接拼接到SQL查询语句中。

3)Web应用中用于连接数据库的用户与数据库的系统管理员用户的权限有严格的区分（如不能执行drop等），并设置Web应用中用于连接数据库的用户不允许操作其他数据库。

4)设置Web应用中用于连接数据库的用户对Web目录不允许有写权限。

5)使用Web应用防火墙。

任意用户密码修改/重置

漏洞描述：

可通过篡改用户名或ID、暴力破解验证码等方式修改/重置任意账户的密码。

测试方法：

密码修改的步骤一般是先校验用户原始密码是否正确，再让用户输入新密码。修改密码机制绕过方式大概有以下三种：

1.如果输入新密码的接口可以直接访问，那么在未知原始密码的的情况下即可直接修改密码，通常知道了他人的用户名即可任意修改他人的密码。

2.如果系统未校验修改密码的用户身份，那么在提交修改密码请求时，攻击者通过输入密码，将用户名或者用户ID修改为其他人的，即可成功修改他人的密码。

3.当修改密码时系统需要电子邮件或者手机短信确认，而应用程序未校验用户输入的邮箱和手机号，那么攻击者通过填写自己的邮箱或手机号接收修改密码的链接和验证码，以此修改他人的密码。

密码重置机制绕过攻击方式主要有以下两种：

1.通过正常手段获取重置密码的链接，猜解链接的组成结构和内容（如用户名或者时间戳的MD5值）。在得知他人邮箱的情况下，构造重置他人密码的链接。

2.在得知他人手机号的情况下，通过穷举手机验证码重置他人的密码。

示例：

我遇到的密码重置漏洞，是忘记密码的时候会自动发送一条手机短信至绑定用户的手机中，而我做的则是在他发送之前拦截，而后修改手机号码，成功的接受到了手机短信，而后重置用户密码。
还有一种是手机短信验证成功后，重新设置密码时拦截数据包，通过修改类似username、userid等方式修改他人的账户密码。

风险分析：

密码修改功能常采用分步骤方式来实现，攻击者在未知原始密码的情况下绕过某些检验步骤修改用户密码。
重置密码过程一般是首先验证注册的邮箱或者手机号，获取重置密码的链接（一般会包含一串唯一的字符串）或者验证码，然后访问重置密码链接或者输入验证码，最后输入新密码。密码重置机制绕过攻击是指在未知他人的重置密码链接或手机验证码的情况下，通过构造重置密码链接或穷举手机验证码的方式直接重置他人的密码。

修复方案：

1.一次性填写校验信息（原始密码、新密码等）后再提交修改密码请求。

2.对客户端提交的修改密码请求，应对请求的用户身份与当前登录的用户身份进行校验，判断是否有权修改用户的密码并对原始密码是否正确也进行判断。

3.不应将用于接收验证信息的手机、邮箱等信息全部明文传到客户端，应对手机、邮箱等信息进行屏蔽处理，或不将此类信息返回到客户端。

4.对原始密码进行了验证的情况下，限制输入原始密码的错误次数，防止攻击者暴力破解原始密码。

5.重置密码链接中的关键信息应随机化，不可预测（例如token机制），且禁止将关键信息返回到客户端。

目录遍历

漏洞描述：

目录浏览漏洞是由于网站存在配置缺陷，存在目录可浏览漏洞，这会导致网站很多隐私文件与目录泄露，比如数据库备份文件、配置文件等，攻击者利用该信息可以更容易得到网站权限，导致网站被黑。

测试方法：

可以利用web漏洞扫描器扫描web应用进行检测，也可通过搜索，网站标题包含“index of”关键词的网站进行访问。

示例：

一般目录遍历都是输入…/…/这种，或者通过御剑进行目录扫描，有的时候会有一些路径可以遍历里面的目录内容
风险分析：

攻击者通过访问网站某一目录时，该目录没有默认首页文件或没有正确设置默认首页文件，将会把整个目录结构列出来，将网站结构完全暴露给攻击者； 攻击者可能通过浏览目录结构，访问到某些隐秘文件（如PHPINFO文件、服务器探针文件、网站管理员后台访问地址、数据库连接文件等）。

修复方案：

目前存在该漏洞的常见中间件为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。

敏感文件信息泄漏

漏洞描述：

敏感数据包括但不限于：口令、密钥、证书、会话标识、License、隐私数据（如短消息的内容）、授权凭据、个人数据（如姓名、住址、电话等）等，在程序文件、配置文件、日志文件、备份文件及数据库中都有可能包含敏感数据。（这里的信息泄露，我包含了常见的已经类似于robots文件等等，包括入侵痕迹残留、打包备份文件遗留等等）

测试方法：

1、检测形式多样，工具爬虫扫描得到敏感文件的路径，从而找到敏感数据，

2、手工挖掘，根据web容器或者网页源代码的查看，找到敏感信息。

示例：

这里我给大家带来了最近比较火的锐捷信息泄露，在源代码中泄露了用户名密码信息

泄露了用户名以及MD5加密的密码

当然了还有一些奇葩的，会直接弹出来测试用户名密码、甚至是用户名密码自动填充等等我觉得只有这些才配成为信息泄露，剩下的泄露个什么加密方式、中间件版本信息啥的太边缘了，懒得测
风险分析：攻击者可通过上述方式获取网站敏感文件，收集网站敏感信息，从而有针对性的进行利用。

修复方案：

1、禁止在代码中存储敏感数据：禁止在代码中存储如数据库连接字符串、口令和密钥之类的敏感数据，这样容易导致泄密。用于加密密钥的密钥可以硬编码在代码中。

2、禁止密钥或帐号的口令以明文形式存储在数据库或者文件中：密钥或帐号的口令必须经过加密存储。例外情况，如果Web容器的配置文件中只能以明文方式配置连接数据库的用户名和口令，那么就不用强制遵循该规则，将该配置文件的属性改为只有属主可读写。

3、禁止在 cookie 中以明文形式存储敏感数据：cookie信息容易被窃取，尽量不要在cookie中存储敏感数据；如果条件限制必须使用cookie存储敏感信息时，必须先对敏感信息加密再存储到cookie。

4、禁止在隐藏域中存放明文形式的敏感数据。

5、禁止用自己开发的加密算法，必须使用公开、安全的标准加密算法。

6、禁止在日志中记录明文的敏感数据：禁止在日志中记录明文的敏感数据（如口令、会话标识jsessionid等）， 防止敏感信息泄漏。

7、禁止带有敏感数据的Web页面缓存：带有敏感数据的Web页面都应该禁止缓存，以防止敏感信息泄漏或通过代理服务器上网的用户数据互窜问题。

框架漏洞

漏洞描述：

开发框架存在的漏洞，如Struts2框架漏洞、shiro等（weblogic反序列化中间件的就不写了）

测试方法：

以Struts2远程命令执行为例：

1.在了解网站所采用的结构框架后，除去伪静态页面，抓包或者读取页面源代码方式，查找到网站系统url为.do和.action结尾类型后，添加相应的远程命令执行代码进行判断。
例如用户可以在http://host.com/X.action?后添加相对应struts2 漏洞的远程命令执行代码，或者直接利用工具K8 Struts2 Exploit.exe进行检测
或使用shiro检测工具进行检测

示例：

使用burp插件进行被动检测
风险分析：

Struts 2是在struts 和WebWork的技术基础上进行了合并的全新的框架。Struts2漏洞类型分为两种，一种是使用缩写的导航参数前缀时的远程代码执行漏洞，另一种是使用缩写的重定向参数前缀时的开放式重定向漏洞。Struts2远程命令执行，属于高危安全漏洞，可使黑客取得网站服务器的权限。这里我们重点描述相关远程命令执行漏洞。Struts2的DefaultActionMapper支持一种方法，可以使用”action:”, “redirect:”, “redirectAction:”对输入信息进行处理，从而改变前缀参数，这样操作的目的是方便表单中的操作。在2.3.15.1版本以前的struts2中，没有对”action:”, “redirect:” , “redirectAction:”等进行处理，导致ongl表达式可以被执行，如s2-020的漏洞中，利用ognl的class.xx这种方式来遍历属性

修复方案：

建议及时更新struts2的版本到最新

SSO认证缺陷

漏洞描述：

SSO认证存在缺陷，可越权登录他人账户。

测试方法：

1.信息传输缺乏安全保证

SSO认证通信过程中大多数采用明文形式传送敏感信息，这些信息很容易被窃取，致使重要信息泄露。另外，在通信过程中大多数方案也没有对关键信息进行签名，容易遭到伪装攻击。

2.Web服务的安全缺陷

由于单点登录基本上是基于Web服务实现的，所以也不可避免的存在Web服务的安全缺陷，如跨站脚本攻击、越权攻击等。

示例：暂无

风险分析：

因为只需要登录一次，所有的授权的应用系统都可以访问，可能导致一些很重要的信息泄露。

修复方案：

建议从以下几个方面进行防御：

1.建议在不影响业务的前提下，使用HTTPS协议传输

2.严格校验SSO认证过程中的用户身份

3.过滤用户传入的参数，对特殊符号进行转义或屏蔽。

暂时就这些吧，一些不是很重要的或者测试方式相似的就不写了

中间件漏洞如weblogic反序列化、jboss的和框架漏洞测试方式一样，都是用工具扫出来的，我就不写了，端口层次、主机漏洞层次的不计入到web漏洞中