姓名：邓勇 班级：软件151
SQL注入攻击：
最容易由程序员的编程疏忽产生的漏洞是SQL注入和XSS，SQL注入的危害严重的情况是泄漏整个数据库的信息，后果不堪设想，XSS的后果严重的情况使用户信息泄漏。以MyBatis为例如何防止SQL注入，如下一条查询语句：
SELECT * from answer a where a.username=#{username}
还可以换个方法写：
SELECT * from user u where u.username=‘${username}‘
在MyBatis里对SQL的处理分为两种，一种是DynamicSqlSource，用于动态的拼接SQL，还有一种是RawSqlSource，静态的SQL（已经预编译）。
MyBatis对#{}的处理就是静态预编译，将SQL参数化，假设用户传的username我们没有过滤，直接用，如果输入的是“ vince‘ or ‘1‘ == ‘1 ”，预计编译的处理会对特定的字符做转义，数据库会去匹配整个字符串，但${}的处理则是拼接成一个新的SQL，拼接后的SQL如下：
SELECT * from user u where u.username=‘vince‘ or ‘1‘ == ‘1‘
是不是结果就不是我们预期的了，严重的情况会使整个数据库被攻破，防止SQL注入的方法有很多，对用户输入的参数进行严格的校验同样也能避免此类问题，不过数据库在设计之初已经帮我们想好了处理方案，就是SQL的预编译，不仅提高执行效率，而且能够防止SQL注入。
跨站脚本攻击：
跨站脚本攻击也是一个开发人员引起的软件漏洞，开发人员没有对展示的文本进行转义处理，导致用户上传的恶意脚本在浏览器中执行了，这也叫代码注入，开发人员也可以通过严格的参数校验和过滤进行避免，也可以利用工具处理，例如Freemarker模板框架里的freemarker.template.utility.StringUtil.XMLEncNA(String)，
用户输入的内容是 <script>alert(‘hel‘);</script> 处理后变成了 <script>alert(‘hel‘);</script> 这样浏览器就不会执行这段脚本，但最终在浏览器上还是展示成 <script>alert(‘hel‘);</script> ，试想一下，如果这里不是alert一个字符串，而是引入一个外部的JS文件，这个文件里的操作是获取用户的Cookie，Cookie里可能包含了某个网站的有效会话SessionID，然后将获取到的数据发到某个邮箱里，恶意的人可以用这个会话登录这个网站，后果可想而知了。
尤其是在有文件上传，用户输入框的地方，开发人员一定要有严格的防范意识，不要依赖客户端JS上的验证，任何用户输入的校验都要验证两次，至少服务器要校验一次。
有一个组织www.owasp.org/ 在web安全方面做的很好，公益性的，贡献了很多资料值得我们开发人员学习。
2013年排名前10的安全漏洞
安全测试指南
安全编码规范
其他安全注意事项：
还有很多容易引起安全漏洞的不良编码习惯，例如对密码的不重视，在软件中留SQL后门等等，当然不是所有漏洞都是开发人员引起的