今天下午上了一堂前端安全的课,挺有意思,记录下来。在上课之前,我对安全的概念是:
用户输入是不可信的,所有用户的输入都必须转义之后才入库。
然后,上面这个这种方式,仅仅是防止SQL注入攻击,避免业务数据库被渗入。
在数据库有了一层安全保护之后,攻击者们的目标,从服务器转移到了用户身上。由此,出现了CSRF攻击和XSS攻击。
CSRF
CSRF (Cross-Site-Request-Forgery) 全称是跨站请求伪造。是攻击者伪造用户身份,向服务器发起请求已达到某种目的的攻击。
GET类型的CSRF
假如有一个业务系统API,其有一个点赞的api是http://domain.com/api/like?pid=111 ,如果想要刷pid为111的点赞,只需要构建一个简单的HTTP请求即可。
<img src='http://domain.com/api/like?pid=111'>
复制
因为Img标签会自动请求src的网络,估当用户浏览一个含有上述img标签的网址的时候,不经意间已经发出一个为pid=111内容进行点赞的操作。
其实这种写操作,最好改成POST的形式,起码增加了攻击者的门槛。
POST类型的CSRF
此类型的特点是,业务系统的api,对于写操作,是用POST的方式,而不是GET的方式。
和GET对比起来,攻击门槛高了一些,不能仅仅依靠img标签来构造HTTP请求,得靠表单来实现HTTP POST了。
<form action="http://domain.com/api/like">
<input type="text" name="xxx" value="1">
</form>
<script>
document.forms[0].submit();
</script>
复制
先准备一个攻击页面,如上面的代码,然后将URL隐藏在预先准备的内容中,分发出去,诱使用户点击攻击页面。
CSRF防御方式
GET类型的CSRF,就应该从代码层面规避,让写操作必须走HTTP POST的方式,这样也更符合HTTP Method的语义。
POST类型的CSRF,由于是跨站攻击,一个简单的防御方式是对HTTP Refer进行判断,如果是非业务域名发起的HTTP请求,则直接过滤处理。
但HTTP Refer并不是百分百可靠,在某些时候,服务器是收不到HTTP Refer值的(例如某些代理环境,例如低版本浏览器)。
所以,HTTP Refer可以用来做CSRF攻击的检测,但防御还需要另外真正的宙斯盾。
根据上面可以知道,所有CSRF攻击,最重要的是伪造攻击URL,如果我们的API,带有一个随机参数,让攻击者没法固定伪造,则可以完美防御CSRF攻击。
防御CSRF,可以在我们请求的参数里面,携带一次性随机Token信息即可。
<form action="http://domain.com/api/like">
<input type="text" name="xxx" value="1">
<input type="text" name="token" value="<?php echo token();?>" style="display:none;">
</form>
### 如何入门网络安全
#### 建议
多看书
阅读永远是最有效的方法,尽管书籍并不一定是最好的入门方式,但书籍的理解需要一定的基础;但是就目前来看,书籍是比较靠谱的入门资料。
现在Web安全书籍比较多,因此大家在学习的过程中可以少走了不少的弯路。如果以上推荐书籍阅读有困难,那就找自己能看得进的 Web 安全的书
当然纸上谈兵终觉浅,最好还是实践一下。
对于那些没有学习方向和资料的同学,可以看下我整理的资源,这份资料经历过社会的实践,可以说是当下全网较全的网络安全知识体系:
①网络安全学习路线
②20份渗透测试电子书
③安全攻防357页笔记
④50份安全攻防面试指南
⑤安全红队渗透工具包
⑥网络安全必备书籍
⑦100个漏洞实战案例
⑧安全大厂内部视频资源
⑨历年CTF夺旗赛题解析
<img src="https://img-blog.csdnimg.cn/img_convert/5038c791428a513aca3d99aac6d0bed5.jpeg" />