再看web安全

web安全原理简单,要的也就是积累,本篇阐述原理思路也用来记录每次遇到的小trick(嗯,就是未完待续,每次遇到就补充)~

二进制安全问题总是因为出现未定义的读写,而web安全问题同样是因为出现了未定义行为,这种未定义可能是基础设施漏洞,是编码逻辑漏洞,也可能是自己并未完全掌握环境特性,所以一般的安全策略都是使用最新的基础设施,深入了解所使用的每一个功能尽最大努力实现设计功能同样多的最终功能,这和最小权限原则相类似。
同样设计时也不要假设信任任何外部,于是也就有了参数过滤,参数过滤方法白名单显然是最小的过滤列表与规则能实现,能够实现上面提到的实现满足设计功能的最少功能的web程序,这里面少量需要关注的也就是过滤无逻辑漏洞,无知识性漏洞(如不完全了解正则表达式及其相关函数的特性)

我的安全观

这是朋友被面试问到的问题,当时自己也想了下,但是前几天翻道哥的白帽子发现更透彻,于是记录:

  1. 防御某种攻击而非某次攻击
  2. 安全问题的本质是信任问题,必须信任最基本的假设,但这种信任越少越好,因为它们一旦被攻破整个体系就再无安全性可言。
  3. 安全是个持续的过程,系统本身一定存在未发现的漏洞而且随着产品迭代升级又会引入新的漏洞
  4. 互联网安全的核心问题是数据安全
  5. 安全原则:默认安全,白名单,最下权限,纵深防御,数据代码分离,不可预测。

浏览器安全

同源策略

安全基石,作用在document上,浏览器脚本只能操作加载它的网页,即同源(域名,协议,端口,主机都相同),其中js不能读写非同源的内容。

服务端攻击

它的攻击目标是服务器,因此危害相对更大!

ssrf

原理

当服务器IO操作的对象由用户指定,若过滤不严将造成此漏洞。即客户端将能控制服务端进行io请求,如网络连接,文件读取等。

作用

危害为 {服务端能做的事}-{客户端能做的事} 这个差集,如:

  1. 任意文件读取
  2. 利用对远端的服务请求,以服务器身份向外发送请求
    可绕过地址访问限制,使用内网服务,实现主机服务扫描等
    伪造的身份向其他非内网服务器发送请求
  3. 实现一些waf绕过

防御

严格的参数过滤。

xxe

原理

与xml注入放在一起,作为一种结构化文档,在服务端被解析时,若注入特殊数据,这些数据将被执行~

作用

  1. 任意文件读写

防御

参数过滤

uploadVul

原理

用户能够上传未定义类型的文件。

危害

当能够向服务端写入任意文件时,写入的文件已经绕过了安全防线,处于某种特殊受信任状态,有如下三类:

  1. 被上传的文件作为配置文件被启用
  2. 被上传的文件作为恶意代码被执行(最常见的上传webshell)
  3. 被上传的文件借用用户对服务端的信任而钓鱼

防御

防御可以追踪文件上传的整个流:

  1. 客户端验证(不安全的)
  2. 服务端对文件类型的验证(后缀和MIME等,需要防解析漏洞)
  3. 服务端对文件清洗(如对图片进行重绘)
  4. 服务端对文件名进行清洗(如使用户无法控制文件名任何字段)

sqli

原理

其原理就是用户输入的数据被当作SQL语句(代码)执行了,既然语句被执行,那么一定会产生相应的结果,理想的是直接返回想要查询的数据,最差也能通过语句执行的时间获取布尔数据。从原理处大致能猜到只要存在SQL注入漏洞,即SQL语句被执行一定能够通过此获取数据,但是若作为一个攻击者,我们的目的是要高效的获取数据,于是有了下面的方法:

  1. 联合注入
  2. 报错注入:构造运行时出错的嵌套的多条语句,第一条语句成功执行后运行时错误,返回第一条执行的结果
  3. 布尔盲注
  4. 时间盲注
  5. 外带注入
  6. 宽字符注入:算绕过技术了,绕过转义符
  7. 二次注入:第一次注入时被转义,当其被查询再插入时再次转义

作用

  1. 最直观的它能获取数据库数据
  2. 根据SQL数据库特性,更能实现一些其他功能:
  • 文件读写
  • 命令执行(可用危险存储过程,写入shell,udf插件)
  • 服务扫描

防御

  1. 让用户的输入不被传入SQL语句中(如使用if语句根据用户输入赋值为相应的开发人员预设的值,但是这在大多数情况下是不现实的)
  2. 让用户的输入不会被解析为代码(如预编译语句绑定参数,安全的存储过程)
  3. 对用户的输入进行过滤(如各种转义)
  4. 加强利用难度(如数据库最小权限,不返回错误等)

配置错误

原理

配置不当

危害

根据配置错误处,危害各种各样,如:

  1. 敏感数据泄露
  2. 危险的解析
  3. 目录列出,目录遍历

客户端

它的攻击目标是客户端,也就是它攻击网站的使用者而非网站本身,危害相对较小但是不容忽视!

xss

原理

客户端(浏览器)会执行网页返回的脚本(主要为JavaScript),若用户能够控制网页的返回内容,让其含恶意代码即可使客户端执行恶意代码,分为三类:

  1. 反射型XSS
  2. 存储型XSS
  3. DOM型XSS(不同于前面两种它会修改DOM结构以使js执行)

它的利用一个是要让服务端返回目标代码,另一个是要让目标代码被执行(如作为事件响应或直接作为\< script >)

危害

它的危害即让客户端执行任意代码,当然由于权限及js本身作用有限,它一般直接危害不到操作系统本身,具体的可以参考Beef提供的功能。

防御

通常的防御就是抓住利用的第二条,让注入的恶意代码不被客户端当作代码来执行,追踪参数路径:

  1. 在输入时清洗关键字
  2. 在输出时清洗关键字
  3. 特别提出,为防止cookie窃取应对其添加httponly属性

一般为了保证语义不变,不应该直接删除关键字,而是利用返回的内容应该作为数据被渲染到页面上这点来处理,例如:

  1. 当参数最终被作为html一部分应该转义为html实体,如htmlspecialchars()
  2. 当参数最终被作为url一部分应该用url编码
  3. 当参数最终被作为js里的数据,应该对关键字做16进制编码并使用""包含。

csrf

原理

http作为无状态的协议需要使用其他方式保存状态与凭证,如使用cookie,它分为关闭浏览器就会失效的会话cookie和一定时期内一直有效的本地cookie,不管怎么说,当用户登陆网站后浏览器将处于被认证状态,使用它浏览网页将会直接使用其权限进行操作,若在用户不知情的情况下浏览器访问某个url即以存储的身份执行了某种敏感操作即为漏洞。

危害

使用户在不知情的情况下以其登陆过的身份执行敏感操作,如修改密码,向好友发信息等

防御

思路为让敏感操作只有用户知情的情况下才能操作:

  1. referer判断:某个操作只有通过某个特定页面跳转到,若不是来自特定页面此操作及非法
  2. 验证码:判断是用户真人操作(含验证密码)
  3. 随机token:和referer判断类似,某个操作只有通过某个特定页面才能操作,这个页面含有一个不可预测的token,那么非用户自身将无法得到这个token,硬编码的无正确token的请求将会失效

其他

http

Host

有的时候需要改Host此时必须在协议后写绝对地址才能成功:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
GET /links/ HTTP/1.1
Host: blog.betamao.me
;;; 可替换为
GET https://blog.betamao.me/links/ HTTP/1.1
Host: lala'
```
### php
#### heredoc
构造的字符串无需引号包围。
```php
$str=<<<A
123456
A;

参考

《白帽子讲web安全》

扫码领红包啦