读书笔记--《白帽子讲安全》
白帽子讲安全读书笔记:
阅读情况:全部看完
来源:kindle电子书
小结:书籍比较早,有些例子可能过时了,但是还是很适合我这种小白看可以系统的了解一下安全方面
属于科普书,里面罗列了常见的安全问题。
个人书籍摘要备忘:
1./浏览器安全/
(1)同源策略:js跨域
(2)沙箱:独立的tab页
(3)恶意网址拦截:挂马网址黑名单
2./xss/
跨站脚本攻击
(1)反射型
向页面注射<script>alert(/xss/)</script>
(2)存储型XSS
存储到服务器
比较常见的一个场景就是,黑客写下一篇包含有恶意JavaScript代码的博客文章,文章发表后,所有访问该博客文章的用户,都会在他们的浏览器中执行这段恶意的JavaScript代码。黑客把恶意的脚本保存到服务器端
(3)payload
1.cookie
2. "><script>alert("hello")</script>
如果有长度限制,可以执行事件方法 "onclick=alert(1)//
4./csrf/
跨站点请求伪造:本质,请求url,参数被攻击者猜测到
防御方法:
验证码
referer check
token(实用)
http://host/path/delete? username=abc&item=123&token=[random(seed)]
同时放在form(可隐藏)和session/cookies中
token保密原则,尽量以form ajax形式提交
5./clickjacking/
点击劫持
点击劫持是一种视觉上的欺骗手段。攻击者使用一个透明的、不可见的iframe,覆盖在一个网页上,然后诱使用户在该网页上进行操作,
此时用户将在不知情的情况下点击透明的iframe页面。通过调整iframe页面的位置,可以诱使用户恰好点击在iframe页面的一些功能性按钮上。
ClickJacking相对于XSS与CSRF来说,因为需要诱使用户与页面产生交互行为,因此实施攻击的成本更高,在网络犯罪中比较少见
(1)falsh动画游戏点击,诱使用户点击不能的位置,完成一些列操作,比如打开摄像头
(2)图片覆盖攻击等
防御方法:
ClickJacking是一种视觉上的欺骗,那么如何防御它呢?针对传统的ClickJacking,一般是通过禁止跨域的iframe来防范。
7./SQL注入/
(1)盲注:
验证注入sql语句能否执行
1.最简单但一般都不会成功
先注入and 1=1看是否能正常返回
再注入and 1=2看是否不能正常返回
2.下面这段Payload,则是利用union 试错:select来分别确认表名admin是否存在,列名passwd是否存在: id=5 union all select 1,2,3 from admin
id=5 union all select 1,2,passwd from admin
/解释select 1,2,3/占位和猜测替换
select * from student union all select 1,2,3,4 from student;
+------+-----------+------+------+
| sid | sname | sage | ssex |
+------+-----------+------+------+
| 1 | mili | 18 | 0 |
| 2 | wangmeili | 18 | 1 |
| 3 | lida | 18 | 1 |
| 4 | zhangsan | 19 | 1 |
| 5 | zhaodade | 19 | 1 |
| 6 | nali | 19 | 0 |
| NULL | NULL | NULL | NULL |
| 1 | 2 | 3 | 4 |
| 1 | 2 | 3 | 4 |
| 1 | 2 | 3 | 4 |
| 1 | 2 | 3 | 4 |
| 1 | 2 | 3 | 4 |
| 1 | 2 | 3 | 4 |
| 1 | 2 | 3 | 4 |
+------+-----------+------+------+
如果占位福的个数和查询的列个数不一致,就会报错,可替换
MariaDB [learn]> select * from student union all select 1,2 from student;
ERROR 1222 (21000): The used SELECT statements have a different number of columns
替换成想要查找的字段sname
MariaDB [learn]> select * from student union all select 1,2,3,sname from student;
+------+-----------+------+-----------+
| sid | sname | sage | ssex |
+------+-----------+------+-----------+
| 1 | mili | 18 | 0 |
| 2 | wangmeili | 18 | 1 |
| 3 | lida | 18 | 1 |
| 4 | zhangsan | 19 | 1 |
| 5 | zhaodade | 19 | 1 |
| 6 | nali | 19 | 0 |
| NULL | NULL | NULL | NULL |
| 1 | 2 | 3 | mili |
| 1 | 2 | 3 | wangmeili |
| 1 | 2 | 3 | lida |
| 1 | 2 | 3 | zhangsan |
| 1 | 2 | 3 | zhaodade |
| 1 | 2 | 3 | nali |
| 1 | 2 | 3 | NULL |
+------+-----------+------+-----------+
预防方法:
1.使用预编译语句?
使用预编译的SQL语句,SQL语句的语义不会发生改变。在SQL语句中,变量用?表示,攻击者无法改变SQL的结构,在上面的例子中,即使攻击者插入类似于tom' or 1=1'也会把这个整体当作一个变量 String query = "SELECT account_balance FROM user_data WHERE user_name = ? ";
$query = "INSERT INTO myCity (Name, CountryCode, District) VALUES (?,?,?)";
2.使用存储过程()
3.检查输入数据类型
4使用安全函数
8./文件上传漏洞 /
webshell脚本上传
1.检查文件后缀名:不应该采取黑名单,应使用白名单
0字节截断 0x00 [\0] %00
2.检查文件头:浏览器的MIMESniff功能实际上也是通过读取文件的前256个字节,来判断文件的类型的。Sniff的功能,常见的攻击技巧是伪造一个合法的文件头,而将真实的PHP等脚本代码附在合法的文件头之后
3.apatch服务器等解析功能远离被利用
预防方法:
1.文件上传的目录设置
设置为不可执行,一般放在专门的静态存储,同时也方便做缓存处理
2.判断文件类型
在判断文件类型时,可以结合使用MIMEType、后缀检查等方式。在文件类型检查中,强烈推荐白名单的方式,黑名单的方式已经无数次被证明是不可靠的。此外,对于图片的处理,可以使用压缩函数或者resize函数,在处理图片的同时破坏图片中可能包含的HTML代码。
3.使用随机数改写文件按的目录和名称
4.单独设置文件服务器的域名
由于浏览器同源策略的关系,一系列客户端攻击将失效,比如上传crossdomain.xml、上传包含JavaScript的XSS利用等问题将得到解决。但能否如此设置,还需要看具体的业务环境。
9/认证于会话管理/
密码:弱密码,多因素认证
session劫持(session写入cookie后,cookie被xss获取到)
session保持攻击
单点登陆sso:On,简称SSO。它希望用户只需要登录一次,就可以访问所有的系统。
10/访问控制/
1rbac (role_based access control)基于角色的访问控制
2越权
从这两个例子中我们可以看到,用户访问了原本不属于他的数据。用户A与用户B可能都属于同一个角色RoleX,但是用户A与用户B都各自拥有一些私有数据,在正常情况下,应该只有用户自己才能访问自己的私有数据。
方案:这种种原因导致了现在数据级权限管理并没有很通用的解决方案,一般是具体问题具体解决。一个简单的数据级访问控制,可以考虑使用“用户组(Group)”的概念。比如一个用户组的数据只属于该组内的成员,只有同一用户组的成员才能实现对这些数据的操作。 此外,还可以考虑实现一个规则引擎,将访问控制的规则写在配置文件中,通过规则引擎对数据的访问进行控制。
3OAuth 与 OpenID都致力于让互联网变得更加的开放。OpenID解决的是认证问题,OAuth则更注重授权。认证与授权的关系其实是一脉相承的,后来人们发现,其实更多的时候真正需要的是对资源的授权。
11./web框架安全/
MVC
struts2漏洞
django095注入漏洞
12/web server安全/
tomcat
apache
ngix
13./ddos/
应用层拒绝服务攻击
DDOS本是利用合理的请求造成资源过载,导致服务不可用。
/网络层ddos/
synflood如此猖獗是因为它利用了TCP协议三次握手设计中的缺陷,而TCP/IP协议是整个互联网的基础
(1)客户端向服务器端发送一个SYN包,包含客户端使用的端口号和初始序列号x; (2)服务器端收到客户端发送来的SYN包后,向客户端发送一个SYN和ACK都置位的TCP报文,包含确认号xx1和服务器端的初始序列号y; (3)客户端收到服务器端返回的SYNSACK报文后,向服务器端返回一个确认号为yy1、序号为xx1的ACK报文,一个标准的TCP连接完成。
SYN flood在攻击时,首先伪造大量的源IP地址,分别向服务器端发送大量的SYN包,此时服务器端会返回SYN/ACK包,因为源地址是伪造的,所以伪造的IP并不会应答,服务器端没有收到伪造IP的回应,会重试3~5次并且等待一个SYNTime(一般为30秒至2分钟),如果超时则丢弃这个连接。攻击者大量发送这种伪造源地址的SYN请求,服务器端将会消耗非常多的资源(CPU和内存)来处理这种半连接,同时还要不断地对这些IP进行SYN+ACK重试。最后的结果是服务器无暇理睬正常的连接请求,导致拒绝服务。
DDOS的攻击与防御是一个复杂的课题,而本书重点是Web安全,因此对网络层的DDOS攻防在此不做深入讨论/
/应用层ddos/
cc攻击
CC攻击的原理非常简单,就是对一些消耗资源较大的应用页面不断发起正常的请求,以达到消耗服务端资源的目的。在Web应用中,查询数据库、读/写硬盘文件等操作,相对都会消耗比较多的资源
预防方法:
1限制请求频率,比如通过ip和cookie锁定一个用户,但是可以通过代理服务器和清空cookie绕过
2验证码