-- web系统的常见安全测试项及检测,验证，修复方案
【官网】：无
应用场景
怎么判断一个web项目是否存在常见的信息安全问题或者潜在漏洞 1)系统安全(是否可能被sql注入,是否可能被提权,是否可能有跨站脚本攻击,是否容易被ddos攻击,是否缺少鉴权). 2) 业务安全. 3) 运维安全.基础资源
实际运营场景
使用须知
请结合实际情况，实际情况可能得从人员管理，权限管理，服务器管理，信息管理规范等各方面入手
配置步骤
A)系统安全.
A1)跨站脚本攻击(xss，全称:Cross-Site Scripting).
<测试> 向可编辑内容的地方输入以下内容并保存：<script> alert（1）</ script>
<验证>看查看保存的内容时是否能运行alert弹窗。如果能则确认了一个xss漏洞。
<修复>对可能输入script的地方进行编码，转义等处理后保存。
A2)sql注入.
<测试>输入 右侧内容（1=1 后面可以自由发挥sql) 观看表现: ‘ or 1=1 -- 或者 ‘ or 1=1 #
<验证>是否造成sql错误或者未知的sql执行结果
<修复>使用参数化处理或者类似EF这种ORM框架。
A3)注册，添加，修改，重置密码的地方需要确保复杂度。
<测试>对123456,admin,password,pwd等明文，hash等进行密码比对，验证是否有很多弱密码。
<验证>是否猜到密码，并进行正常登录
<修复>增加强制校验密码复杂度，不达标的不予通过，定期提醒更换密码等。
1)至少16个字符,至少包含特殊字符，数字，大小写字母等几种类型。
2)定期更换。
3)避免包含有意义的短语，单词等。
A4)上传文件时的漏洞.
<测试>提交意外的文件类型，意外大小的文件, 提交一个恶意文件但传输中途修改包内容.
尝试用Burp Suite抓包，通过修改包内的Content-Type值进行上传，将application/octet-stream修改为image/jpeg。
上传成功，右击图片，选择复制图像地址，图像地址就是恶意文件的地址
<验证>是否能提交成功.
<修复>
1)增加对上传文件的大小，类型的校验：
在判断文件类型时，可以结合使用MIME Type、后缀检查等方式。在文件类型检查中，强烈推荐白名单方式，黑名单的方式已经无数次被证明是不可靠的。此外，对于图片的处理，可以使用压缩函数或者resize函数，在处理图片的同时破坏图片中可能包含的HTML代码。
2)增加对上传目录的磁盘目录权限的管理(不允许执行，不允许创建目录)
参考: http://config.net.cn/server/serversecurity/c8b5e2d4-8cfc-4fee-94a8-a60335bea670-p1.html
3)将IIS,nginx升级到最新。
4）单独设置文件服务器的域名。
使得恶意文件的运行遇到跨域问题而部分失效。
5)使用随机数改写文件名和文件路径.
在某些环境中，用户能上传，但不能访问。如果应用了随机数改写了文件名和路径，将极大地增加攻击的成本。再来就是像shell.php.rar.rar和crossdomain.xml这种文件，都将因为重命名而无法攻击
A5)js,jquery等第三方库的老版本因漏洞而需要更新到更新版本。
<测试>查看各库的版本，官网的安全漏洞通知。
jQuery 1.x，2.x，bootstrap 3.x和Moment.js已达到使用寿命（EOL），这意味着它们将来将不会收到安全更新.
<验证>检查应用版本情况.
<修复>更新到最新，跟进官网的推荐方案。
A6)Cookie的安全管理.
<测试>cookie在浏览器抓包时的表现.
<验证>
<修复>设置httpOnly(只能传输，无法通过js访问)
确保加密，有时效性。
确保进入https的时候才产生cookie。
A8)安全凭据通过url形式传递。
<测试> 查看url的相关参数含义，分析。
<验证> 容易被恶意存储，在异地，或其它时间发起请求(重放).
<修复> 向页面输出下面这段，会自动进行跳转
<form id=”form_redirect” action=”要跳转的url” method=”post”>
<input type=”hidden” name=”token” value=”token的值”>
<input type=”hidden” name=”redirectUrl” value=”redirect的值”>
</form>
<script type="text/javascript">
document.forms["form_redirect"].submit();
</script>
A9)免登录，匿名访问的api或action问题.
检查系统中[AllowAnonymous]特性是否滥用，避免新手程序员因为复制粘贴导致的权限错误声明。
A10)http明文发送密码等信息。
1)对密码之类的要么js进行md5.
2)将密码进行rsa公钥加密之后再发送到服务器。
A11）数据库连接密码，第三方api或sdk的密钥等不能放到已经被git或svn管理的代码或配置文件中。
1)建议搞一个网络配置中心，用时拿到。并且区分开发环境和生产环境。
2)放到用户私密信息中。
B)业务安全.
B1)敏感信息进行脱敏和加工处理.
1)类似客户手机号，客户邮箱等联系方式，可以在公开报表或给不直接相关人看时替换中间4位为*.
2）类似住址之类的隐私信息在非必要时不展示。
3) 类似工资之类的数据，避免展示出来。
4)如果从生产环境拿数据库到开发环境部署之前，需要先脱敏。
5)对于服务器端的敏感文件，首先不要保存在站点目录下，其次不要使用简单有规律的文件名，应该使用加盐hash之后的值作为文件名。
B2)未采用事务保证业务完整性.
<测试>制造部分db操作失败，看是否有确保完整性.
<验证>db数据检查
<修复>适当采用事务，在性能和一致性之间寻找平衡。
[注]对于同时包含db事务和api的，可以事务先执行但不提交，等api执行成功之后再提交，否则回滚。
B3)角色权限规划或应用不合理导致部分角色可以提权.
<测试>检测低权限用户是否能创建，管理其它用户。
<验证>结合实际，看看提权操作是否合理.
<修复>梳理并完善角色权限用户三者关系，从更高的角度看问题.
B4)确保一个用户只有一个会话(一个账号同时只能在一个地方登录).
<测试>同一时间，在两个浏览器上登录同一个账号.
<验证>是否可以正常使用.
<修复>增加会话凭据校验，每次登录都生成一个，页面刷新时都检查是否和登录生成的会话凭据一致，不一致则退出。
B5)发布的客户端，移动端app之类的产品没有混淆保护。
1)未混淆，加壳保护的产品将很容易变成别人的产品了，因为别人拿过去直接二次开发。
C)运维安全.
C1)公司第三方服务（支付，社交分享，第三方统计等）的账号申请规范.
1)必须通过公司的企业邮箱去申请相关的第三方服务账号。
2)绑定的手机号必须是公司核心负责人的手机号。
3)认证的身份信息必须是公司核心负责人的身份信息，防止员工离职之后的一系列问题。
4）不同服务的密码必须为独立的(禁止共享一个密码)强密码（包含数字，大小写字母，特殊字符），长度至少16位，且不含弱密码。
C2)员工工作相关的账号，密码/密钥, url通过keepass之类的工具管理保存。
1)方便员工离职时的交接.
2)方便管理众多的，不同的站点的账号和复杂密码，避免因为追求简单好记而设置弱密码或共享密码的问题。
3)方便通过一个管理密码管理众多的应用服务的账号，密码。
keepass官网: https://keepass.info/
C3)api没有加速率和访问配额限制,可能导致服务被搞崩溃。
1）增加用户的访问速率，单位时间的访问配额。（类似耗时的，短信/邮件，付费服务等)
C4)针对不同的微服务，业务模块专门提供独立的数据库访问连接，其中还可以拆分为针对部分表的读写权限.
1)避免不熟悉的开发人员操作不想关的数据表，实现越权处理。最后导致风险不可控。
C5)测试/探针诊断工具被公布到了公网，导致被恶意查看大量系统的相关信息。
删除测试页面以及无用文件，例如test.cgi，phpinfo.php，info.pho， .svn/entries等
C6)没有操作日志，无法审计行为。
必要的操作日志可以在后期查看，回顾很多问题.
常见问题
快速入门
无
