写在前面

重要的事多说几遍

本文对学习基础、面试、了解安全都有辅助的作用
觉得本文对您有帮助的朋友们,请您动动小手点赞、收藏加关注哦~
觉得本文对您有帮助的朋友们,请您动动小手点赞、收藏加关注哦~
觉得本文对您有帮助的朋友们,请您动动小手点赞、收藏加关注哦~

本文一共9150字,预计阅读时间50分钟

脑图地址,一切从这里开始

白帽讲Web安全脑图


目录

  • 写在前面
    • 重要的事多说几遍
    • 脑图地址,一切从这里开始
  • 第一篇 世界观安全
    • 第一章 我的世界安全观
      • 1.1 Web安全简史
      • 1.2 黑帽子,白帽子
      • 1.3 返璞归真,揭秘安全的本质
      • 1.5 安全三要素
        • 机密性
        • 完整性
        • 可用性
      • 1.6 如何实施安全评估
        • 资产等级划分
        • 威胁分析(威胁建模STRIDE模型)
          • Spoofing(伪装)
          • Tampering(篡改)
          • Repudiation(抵赖)
          • InformationDisclosure(信息泄露)
          • Denial of Service(拒绝服务)
          • Elevation of Privilege(提升权限)
        • 风险分析
        • 设计安全方案
      • 1.7 白帽子兵法
        • Secure By Default 原则
        • 纵深防御原则
        • 数据与代码分离(数据就是数据,不能被执行为代码)
        • 不可预测性-->加密算法、随机数、哈希(随机数,比如抓取页面id=随机数,防止csrf的随机数token)
  • 第二篇 客户端脚本安全
    • 第二章 浏览器安全
      • 2.1 同源策略
      • 2.2 浏览器沙盒
      • 2.4 高速发展的浏览器安全
    • 第三章 跨站脚本攻击
      • 3.1 简介
        • 反射型XSS
        • 存储型XSS
        • DOM型XSS
      • 3.2 XSS攻击进阶
        • 攻击手段
      • XSS攻击技巧
      • XSS网站设计的防御
    • 第四章 跨站点请求位置(CSRF)
      • 攻击手段
      • 防御手段
        • 验证码
        • Referer Check
        • TokenCSRF
    • 第五章 点击劫持
      • 防御
    • 第六章 HTML5安全
      • HTML 5 新标签
        • iframe的sandbox
        • noreferer(referer是指之歌这个请求的来源是哪一个网站 有防盗、防止恶意请求)
        • Canvas
      • 其他安全问题
        • 跨域新技巧
          • postMessage
        • Web Storage
  • 第三篇 服务器端应用安全
    • 第七章 注入攻击
      • SQL注入
        • SQL注入
          • SQL注入攻击的两个条件
          • 回显
          • 盲注
            • 布尔盲注
            • 时间盲注
            • Timing Attack
        • 数据库攻击技巧
          • lib_mysqludf_sys提供的几个函数
          • xp_cmdshell
          • 宽字符攻击(未考虑双字节字符的问题)
          • SQL Column Truncaton
        • 正确防御SQL注入
      • 其他注入攻击
    • 第八章 文件上传漏洞
      • FCKEditor文件上传漏洞
      • 绕过
      • 各类系统的文件解析问题
        • apache解析漏洞
        • IIS6文件解析漏洞
        • PUT方法
      • 防御
        • 文件上传的目录设置为不可执行
        • 判断文件类型
        • 使用随机数
    • 第九章 认证与会话管理
      • 认证与授权
        • 目的
        • MD5
      • Session与认证
      • Session Fixation攻击
      • Session保持攻击
      • 单点登录 SSO
        • OpenID
    • 第十章 访问控制
      • 垂直权限
      • 水平权限
      • OauthOAuth
    • 第十一章 加密算法与随机数
      • 加密攻击
        • 唯密文攻击
        • 已知明文攻击
        • 选择明文攻击
        • 选择密文攻击
      • 密码学里的基本原则
      • 伪随机数问题
    • 第十二章 Web框架安全
    • 第十三章 应用层拒绝服务攻击
      • 定义
      • 三次握手的缺陷
      • 应用层DDOS攻击
        • CC攻击
        • 验证码
        • 防御DDOS——增加人机认证
        • 资源耗尽攻击
          • Slowloris
          • HTTP POST DOS
          • Server Limit DOSWeb Server
    • 第十四章 PHP安全
      • 文件包含漏洞
        • 使用方法
        • 原理
        • 远程文件包含
        • 文件包含使用方法
        • 远程文件包含使用方法
      • 变量覆盖漏洞
        • 实现
    • 第十五章 Web Server配置安全
      • Apache安全
        • 使用root或者是admin权限运行Apache的结果可能是灾难性的
      • Nginx安全
  • 第四篇 互联网公司安全运营
    • 第十六章 互联网业务安全
      • 产品需要什么样的安全
        • 什么是好的安全方案
      • 业务逻辑安全
      • 邮箱钓鱼
    • 第十七章 安全开发流程
      • 需求分析与设计
      • 开发阶段
      • 测试阶段
    • 第十八章 安全运营
      • 安全监测
      • 入侵检测
      • 紧急响应
  • 脑图

第一篇 世界观安全


第一章 我的世界安全观


1.1 Web安全简史

在Web发展初期由于对安全问题认知认识不足,导致发生过许多的安全问题,且遗留下许多历史问题:如PHP语言至今只能依靠较好的代码规范来防范文件包含漏洞,而无法从语言本身来杜绝此类安全问题的发生。常见的安全漏洞:SQL注入、XSS攻击、CSRF。

1.2 黑帽子,白帽子

白帽子是指那些精通安全技术,工作在反黑客领域的专家们,他们的工作出发点是解决所有的安全问题,所以他们看待问题的方面更加全面、宏观。黑帽子是指使用黑客技术对网络进行破坏、甚至是进行犯罪的群体,他们的主要目的是入侵系统,找到对他们有效的数据,因此他们只需要以点为突破,找到对他们最有利的一点进行渗透,所以他们思考问题的方向是有选择性的、微观的。

1.3 返璞归真,揭秘安全的本质

通过一个安全检查的过程,梳理未知的人或物,将其划分为不同的信任级别的区域,两个不同信任域之间的边界叫做信任边界。
安全问题的本质是信任问题。安全方案的设计基础是建立在信任关系之上的,例如保管文件的“锁”,你得确保锁的工匠是信任的,他没有私自保管一把额外的钥匙;抽屉的工匠失是信任的,他没有给抽屉安装后门;钥匙也需要保管在一个安全不会出现问题的地方。

1.5 安全三要素

机密性

保护数据内容不会泄露,加密是完成机密性的常见手段。

完整性

要求保护数据内容是完整的、没有被篡改的。常见的保证一致性的手段是数字签名。

可用性

保护资源“随需而得。例如:防范DOS攻击。

他们在安全领域还可以扩充增加可审计性、不可抵赖性等,但最重要、最基本的还是机密性、完整性、可用性。

1.6 如何实施安全评估

资产等级划分

明确工作的目标是什么,要保护什么。互联网的核心问题是数据安全的问题,对互联网公司的资产进行等级划分就是对数据做等级划分。有的公司关心客户数据,有的公司关心员工资料信息,所以根据公司的业务的不同,对其进行的侧重点也不同。

威胁分析(威胁建模STRIDE模型)

Spoofing(伪装)

冒充他人身份

Tampering(篡改)

修改数据或代码

Repudiation(抵赖)

否认做过的事

InformationDisclosure(信息泄露)

机密信息泄露

Denial of Service(拒绝服务)

拒绝服务

Elevation of Privilege(提升权限)

未经授权获得许可

风险分析


根据风险因素所对应的权重进行相加算出权值将12-15分之间的定义为高威胁。将8-11分之间的定义为中威胁。将0-7分之间的定义为低威胁。

设计安全方案

针对资产等级划分、威胁分析、风险分析阶段评估出一个合适的解决方案。

1.7 白帽子兵法

Secure By Default 原则

制定黑名单、白名单。白名单相较于黑名单来说更安全,但白名单并不是完全安全的,因为安全建立与信任,白名单中若出现不安全的名单那么信任列表将会变得不可信。

最小权限原则授予主体必要的权限,不要过度授权,这样能有效的减少系统、网络、应用、数据库出错的机会。

纵深防御原则

从不同层面、不同角度对系统做出整体的解决方案,而不是一个安全方案做两遍或者是多遍(木桶理论)。

在正确的地方做正确的事,防止造成”乌龙“(例如XSS过滤关键字可能会过滤“1<2”->”1 2“.

数据与代码分离(数据就是数据,不能被执行为代码)

不可预测性–>加密算法、随机数、哈希(随机数,比如抓取页面id=随机数,防止csrf的随机数token)


第二篇 客户端脚本安全


第二章 浏览器安全


2.1 同源策略

同源策略限制了来自不同源(origin)的文档和脚本。这一策略极其重要,如果没有同源策略,可能a.com的一段JS脚本,在b.com未曾加载此脚本时,也可以随意修改b.com的页面(在浏览器显示中)。为了不发生混乱,浏览器提出“Origin”(源)的概念。来自不同Origin的对象无法相互干扰。

从上表可以看出,影响”源”的因素有:

1.host(域名或IP地址)
2.子域名
3.端口
4.协议

需要注意的是,对于当前页面来说,页面内存放JS文件的域并不重要,重要的是加载JS的页面所在的域是什么。举例说明:
a.com通过代码<script src=http://b.com/b.js ></script>加载了b.com上的b.js。因为b.js是运行在a.com上的,所以b.js的域就是a.com。
在浏览器中,<script> <img> <iframe> <link>等标签都可以跨域加载资源,而不受同源策略的限制。这些带”src”属性的标签每次加载时,实际上是由浏览器发起了一次GET请求。不同于XMLHttpRequest的是,通过src属性加载的资源,浏览器限制了JS的权限,使其不能读,写返回的内容。对于XMLHttpRequest,它收到同源策略的约束,不能跨域访问资源,在AJAX应用的开发中尤其需要注意到这一点。

2.2 浏览器沙盒

Sandbox 即沙箱,计算机技术发展到今天,Sandbox已经成为泛指“资源隔离类模块”的代名词。Sandbox的设计目的一般是为了让不可信任的代码运行在一定的环境中,限制不可信任的代码访问隔离区之外的资源。如果一定要跨越Sandbox边界产生数据交换,则只能通过指定的数据通道,比如经过封装的API来完成,在这些API中会严格检查请求的合法性。

2.4 高速发展的浏览器安全

浏览器对地址的解析便利可能会被黑客所利用,可以通过这些绕过一些安全模块或者是安全软件。如(“xxx.xxx.com\abc”->“xxx.xxx.com/abc”)


第三章 跨站脚本攻击


3.1 简介

反射型XSS

反射型XSS只是简单地把用户输入的数据“反射”给浏览器。也就是说,黑客往往需要诱使用户“点击”一个恶意链接,才能攻击成功。反射型XSS也叫做“非持久型XSS”

存储型XSS

存储型XSS会把用户输入的数据“存储”在服务器端。这种XSS具有很强的稳定性。比如博客网站若被写下了包含有恶意JavaScript代码,后面每个访问这个博客的用户都会执行一遍这个代码。

DOM型XSS

通过修改页面的DOM节点形成的XSS

3.2 XSS攻击进阶

攻击手段

可以利用XSS payload来读取Cookie,将其发送给服务端。但Cookie劫持并非所有的时候都会有效,有的网站可能会在Set-Cookie时给关键的Cookie植入HttpOnly标识;有的网站会把Cookie与客户端IP进行绑定。他们常用的攻击手段都是:制作含有盗取cookie的网页->用户点击这个网页->盗取浏览器上的cookie
使用JavaScript、XmlHttpRequest等方法构造GET、POST请求,借此做到非法删除、添加、盗取页面等。
制作与官方类似的界面进行钓鱼,盗取账号、密码。
识别用户的浏览器(useragent、或是根据浏览器的特色功能)、软件,借此来获取浏览器、操作系统信息,方便接下来的精准攻击。
根据css的style,浏览过的超链接要变颜色,根据此盗取浏览过的链接
获取用户的真实IP(借用Java Applet)
蠕虫病毒

XSS攻击技巧

利用url字符编码
将XSS payload写到别处,使用更短的语句绕过长度限制。location.hash不会在http中进行发送,所以是藏代码的好地方,注意去除第一个#即可。
使用字节拼接注释掉有限制长度的控件。使用<base>标签伪造图片、链接、脚本
使用window.name

XSS网站设计的防御

HttpOnly:JavaScript禁止访问带有HTTPOnly属性的Cookie。
Apache支持的Header的TRACE能绕过此读取Cookie。输入检查对用户输入的字符进行输入检查,像是<、>、"、"等应该将其进行过滤或者是编码。
输出检查对于不同的情况对用户能输入的字符进行编码HTML代码里插入的话使用HTMLEncode<script>中插入的话使用JavaScriptEncodeCSS中使用encodeForCSS()函数
处理富文本时尽量对标签使用白名单


第四章 跨站点请求位置(CSRF)


攻击手段

浏览器所持有的Cookie分为两种:一种是“Session Cookie”,又称”临时Cookie”;另一种是”Third-party Cookie”,也称为“本地Cookie”。
两者的区别在于:
Third-party Cookie是服务器在Set-Cookie时指定了Expire时间,只有到了Expire时间后Cookie才会失效,所以这种Cookie会保存在本地,而Session Cookie则没有指定Expire时间,所以浏览器关闭后,Session Cookie就失效了。
在浏览网站的过程中,若是一个网站设置了Session Cookie,那么在浏览器进程的生命周期内,即使浏览器新打开了Tab页,Session Cookie也都是有效的。Session Cookie保存在浏览器进程的内存空间中,而Third-party Cookie则保存在本地。
例如IE浏览器,从一个域的页面中,要加载另一个域的资源,由于安全的原因,IE会阻止Third-party Cookie的发送,而只发送Session Cookie。
P3P能够使<iframe>、<script>等标签在IE中不在拦截第三方Cookie的发送
不光光是GET请求会引起CSRF攻击,通过构造POST请求提交表单也能进行攻击。例如Gmail通过诱导用户点击恶意网站通过构造表单使用用户的临时Cookie进行攻击。
Flash CSRF 通过Flash发起网络请求进行攻击,但从IE8开始已经不支持。
CSRF Worm百度的sn参数对应给某个好友发送短消息,另一个接口可以查询某个用户的所有好友。借此向好友发送一张带有指向恶意页面的CSRF图片之时,加载出来后又会向这个人的所有好友发送这张带有恶意指向CSRF页面的图片。

防御手段

验证码

破坏CSRF依靠在用户不知情的情况下进行网络请求,这是一个辅助手段,因为不能在所有网络请求进行验证法验证。

Referer Check

检查网络请求是否为规定的来源,例如进入百度界面后,浏览百度的某个界面时referer应该是百度,而点击别人的链接由别人界面发起的网络请求的referer一定不是百度。

TokenCSRF

为什么能够攻击成功?其本质原因是重要操作的所有参数都是可以被攻击者猜测到的。
攻击者只有预测出URL的所有参数与参数值,才能成功地构造一个伪造的请求;反之,攻击者将无法攻击成功。
出于这个原因,可以想到一个解决方案:把参数加密,或者使用一些随机数,从而让攻击者无法猜测到参数值,这是”不可预测性原则”的一种应用。


第五章 点击劫持


点击劫持是一种视觉上的欺骗手段。攻击者使用一个透明的,不可见的iframe,覆盖在一个网页上,然后诱使用户在该网页上进行操作,此时用户在不知情的情况下点击透明的iframe页面。恰好在功能性按钮上,进而欺骗、劫持。

防御

frame busting防止iframe嵌套
X-Frame-Options头、Firefox的NoScript


第六章 HTML5安全


HTML 5 新标签

iframe的sandbox

allow-same-origin:允许同源访问
allow-top-navigation:允许访问顶层窗口
alllow-froms:允许提交表单
allow-scripts:允许执行脚本

noreferer(referer是指之歌这个请求的来源是哪一个网站 有防盗、防止恶意请求)

noreferer就能在需要时的请求相关地址的时候不再发送带有referer的HTTP头,保护一些敏感信息。

Canvas

获取图像、操作像素,构造出图片信息。借此我们可以获取验证码的图片,从而构造、读取出验证码。

其他安全问题

跨域新技巧

HTTP header:Access-Control-Allow-Origin
postMessage

跨窗口发送消息,需验证Domain(域)甚至是URL防止有来自非法页面的消息
当接入的消息要写入HTML甚至是script中时,应该进行安全检查,防止出现DOM型XSS

Web Storage

数据库,防止恶意代码存放入数据库


第三篇 服务器端应用安全


第七章 注入攻击


SQL注入

SQL注入

SQL注入攻击的两个条件

用户能够控制数据的输入(变量)
原本要执行的代码,拼接了用户的输入错误

回显

回显披露了敏感信息,对此,攻击者构造SQL注入也更能够得心应手

盲注

根据页面的变化来判断是否注入成功

布尔盲注

根据加一个布尔判断页面是否变化例如:and 1=2and 1=1and mid()

时间盲注

根据返回时间来判断是否注入正确/错误and if(1=1,1,sleep(1))即不延迟
and if(1=2,1,sleep(1))即延迟一秒后回显

Timing Attack

BENCHMARK(count,expr)将表达式expr执行count次。
into outfile写文件,写入web shellload file读取文件

数据库攻击技巧

and substring(@@version,1,1)==4 如果MySQL的版本为4的话,则页面会返回true
union all select 1,2,3 from admin 猜数据库中是否有表名为admin的表存在
union all select 1,2,password from admin 猜数据库中是否有表名为admin的表下面为pssword的列名

通过判断字符的范围一步步判断字段的具体值

and ascii(substring((select concat(username,0x3a,passwd) from users limit 0,1),1,1))>64
and ascii(substring((select concat(username,0x3a,passwd) from users limit 0,1),1,1))>96
and ascii(substring((select concat(username,0x3a,passwd) from users limit 0,1),1,1))>100
and ascii(substring((select concat(username,0x3a,passwd) from users limit 0,1),1,1))>97
lib_mysqludf_sys提供的几个函数

sys_eval,执行任意命令,并将输出返回
sys_exec,执行任意命令,并将退出码返回
sys_get,获取一个环境变量
sys_set,创建或修改一个环境变量

xp_cmdshell
宽字符攻击(未考虑双字节字符的问题)

例如0xbf27->0xbf5c27->字符+0x27

SQL Column Truncaton

字符超长修改admin密码

正确防御SQL注入

使用预编译语句,变量就是变量,语句就是语句
使用存储过程检查数据类型,比如限制输入类型为int
使用安全函数,编码
使用最小权限原则

其他注入攻击

XML注入
代码注入
CLRF通过回车换行符来达到修改日志的、XSS的目的,“0x0d"、”0x0a“


第八章 文件上传漏洞


文件上传漏洞是指用户上传了一个可执行的脚本文件,并通过此脚本文件获得了执行服务器端命令的能力。
“文件上传”功能本身没有问题,但有问题的是文件上传后,服务器怎么处理,解释文件。如果服务器的处理逻辑做的不够安全,则会导致严重的后果。
大多数情况下,文件上传漏洞一般都是指“上传Web脚本能够被服务器解析”的问题,也就是通常说的webshell的问题。要完成这个攻击,要满足几个条件:
1.上传的文件能够被Web容器解释执行。所以文件上传后所在目录要是Web容器所覆盖到的路径。
2.用户能够从Web上访问这个文件。如果文件上传了,但用户无法通过Web访问,或者无法使得Web容器解释这个脚本,就不能称之为漏洞。
3.用户上传的文件若被安全检查,格式化,图片压缩等功能改变了内容,则可能导致攻击不成功。

FCKEditor文件上传漏洞

FCKEditor文件上传后会保存在/UserFiles/all/目录下,由于其只限制"php"、“php3”、“php5”、"asp"等,黑名单是非常不好的设计思想,借此我们可以上传“php2”、“php4”、“inc”、“pwml”、“cer”等文件。

绕过

使用0x00字符例如上传xxx.php[\0].jpg,[\0]会被php、C等代码认为是终止符,将后面的.jpg截断。

瞒天过海,使用jpg的文件头偷偷藏下php代码。(注意,需要后缀名以便于调用php解释器)

各类系统的文件解析问题

apache解析漏洞

在Apache1.x,2.x中,有以下特性:对于文件名的解析是从后往前解析的,例如xx.php.rar.rar,由于Apache的mime.types文件下没有.rar这个文件类型,所以这会将其遍历解析为php类型的文件

IIS6文件解析漏洞

当文件名为abc.asp;abc.jpg,由于“;”会将其解析为abc.asp错将/*.asp/目录下的所有文件都以asp文件格式进行解析,例如http://www.abc.com/path/xyz.asp/abc.jpg这时就会将abc.jpg以asp文件格式进行解析

PUT方法

能够上传文件到指定的目录 下,MOVE方法能够将文本文件改写为脚本文件

防御

文件上传的目录设置为不可执行

使得攻击者即使上传了脚本文件,服务器也不得进行执行

判断文件类型

使用白名单的方式

使用随机数

改写文件名和文件路径使用随机数进行重命名,使得文件名进行改写从而使文件不能执行例如shell.php.rar.rar


第九章 认证与会话管理


认证与授权

目的

认证的目的是为了认出用户是谁,而授权的目的是为了决定用户能够做什么。

钥匙在认证的过程中,被称为“凭证”(Credential),开门的过程,对应的是登录(Login)。可是开门之后,什么事情能做,什么事情不能做,就是“授权”的管理范围了。开门之后,“能否进入卧室”这个权限被授予的前提,是需要识别出来的人到底是主人还是客人,所以如何授权是取决于认证的。
持有主人钥匙的人一定是主人吗?钥匙仅仅是一个很脆弱的凭证,其他的有诸如指纹,人脸,声音等生物特征来识别一个人的凭证。
认证实际上就是一个验证凭证的过程。

MD5

密码的保存必须是不可逆的加密方式进行加密,常见的有MD5和SHA-1彩虹表可以对MD5进行破解。彩虹表的思路是收集尽可能多的密码明文和明文对应的MD5值。这样只需要查询MD5值,就能找到该MD5值对应的明文。
为了避免密码哈希值泄露后,黑客能够直接通过彩虹表查询出密码明文,在计算密码明文的哈希值时,增加一个“Salt”。“Salt”是一个字符串,它的作用是增加明文的复杂度,并使得彩虹表一类的攻击失效。

Session与认证

Session是指一个会话,当用户对于同一网站页面进行请求时,为了告诉是哪个用户进行页面的浏览,那么直接告诉服务器使用哪一个Session,浏览器只需要把当前用户持有的SessionID告知服务器即可。
SessionID除了可以加密保存在Cookie中,也可以直接写入URL中。但直接写入URL中的话可能会被直接获得导致被非法授权。

Session Fixation攻击

黑客构造一个包含SessionID的URL,诱导用户进行登录,由于用户进行登录了,所以这个SessionID是有效的,这是黑客就可以使用这个URL进入这个用户的账户。

Session保持攻击

通过一直不断地刷新网页来达到Session不过期通过
XSS攻击将Cookie的Expire设置为永不过期

单点登录 SSO

它希望用户只需要登录一次,就可以访问所有的系统

OpenID

使用URL作为每一个用户的身份标识,用户只需要提供他的OpenID和他的OpenID的提供者,就能够首先先跳转到这个OpenID的提供方进行验证之后,重定向会网站。


第十章 访问控制


在Linux中,常见的访问控制有读、写、执行三种。不同用户对其三种的权限可能都不相同。在Web应用中,根据访问客体的不同,常见的访问控制可以分为:
1.“基于URL的访问控制”,
2.“基于方法的访问控制”,
3.“基于数据的访问控制”。

垂直权限

访问控制实际上是建立用户与权限之间的对应关系。现在广泛的做法是,“基于角色的访问控制(Role-Based Access Control)”,简称RBAC。不同的角色权限是有高低之分的,高权限角色往往能够访问低权限的角色资源,而低权限访问高权限角色的资源是往往被禁止的。

水平权限

相同权限下不同角色的不同资源。
但借此可能会触发水平越权的情况。

OauthOAuth

是一个在不提供用户名和密码的情况下,授权第三方应用访问Web资源的安全协议。
OAuth与OpenID都致力于让互联网变得更加的开放。OpenID解决的是认证问题,OAuth则更注重授权。认证和授权的关系其实是一脉相承的,后来人们发现,其实更多的时候真正需要的是对资源的授权。


第十一章 加密算法与随机数


加密攻击

唯密文攻击

仅知道密文对其进行攻击

已知明文攻击

是指黑客不仅知道密文,还知道这些密文所对应的明文。

选择明文攻击

攻击者不仅能得到一些密文和明文,还能选择用于加密的明文

选择密文攻击

攻击者可以选择不同的密文进行解密

密码学里的基本原则

密码系统的安全性应该依赖于密钥的复杂性,而不应该依赖于算法的保密性。
在安全领域里,选择一个足够安全的加密算法不是困难的事情,难的是密钥管理。
最常见的错误,就是将密钥硬编码在代码里。对于Web应用来说,常见的做法是将密钥(包括密码)保存在配置文件或者数据库中。密钥所在的配置文件或数据库需要严格的控制访问权限。同时也要确保运维或DBA中具有访问权限的人越少越好。
一个比较安全的密钥管理系统,可以将所有的密钥(包括一些敏感配置文件)都集中保存在一个服务器(集群)上,并通过Web Service的方式提供获取密钥的API。每个Web应用在需要使用密钥时,通过带认证信息的API请求密钥管理系统,动态获取密钥。Web应用不能把密钥写入本地文件中,值加载到内存,这样动态获取密钥最大程度地保护了密钥的私密性。密钥集中管理,降低了系统对于密钥的耦合性,也有利于定期更换密钥。

伪随机数问题

伪随机数是通过一系列的数学算法生成的随机数,所以可能会导致伪随机数不够随机的现象产生。所对应的真随机数就是物理系列所生成的随机数,比如电压的波动,硬盘磁头读/写时的寻道时间,空中电磁波的噪声等。

通过时间->MD5形成的随机数可能会被猜解

使用seed产生的随机数可能会被暴力破解


第十二章 Web框架安全


数据的处理是复杂的,数据经过不同逻辑的处理后,其内容可能出现变化。比如数据经过toLowercase,会把大写变成小写;而一些编码和解码,则可能把GBK变成Unicode。所以一个优秀的安全方案 应该在正确的地方做正确的事,考虑数据可能的变化,认真斟酌安全检查的插入时机。


第十三章 应用层拒绝服务攻击


定义

分布式拒绝服务攻击,将正常请求放大了若干倍,通过若干个网络节点同时发起攻击,以达成规模效应。这些网络节点往往是黑客们所控制的“肉鸡”,数量达到一定规模后,就形成了一个“僵尸网络”。大型的僵尸网络,甚至达到了数万、数十万台的规模。如此规模的僵尸网络发起的DDOS攻击,几乎是不可阻挡的。
常见的DDOS攻击有SYN flood、UDP flood、ICMP flood等。其中 SYN flood是一种最为经典的DDOS攻击,其发现于1996年,但至今仍然保持着非常强大的生命力。SYN flood如此猖獗是因为它利用了TCP协议设计中的缺陷,而TCP/P协议是整个互联网的基础,牵一发而动全身,如今想要修复这样的缺陷几乎成为不可能的事情。

三次握手的缺陷

(1)客户端向服务器端发送一个SYN包,包含客户端使用的端口号和初始序列号x
(2)服务器端收到客户端发送来的SYN包后,向客户端发送一个SYN和ACK都置位的TCP报文,包含确认号x+1和服务器端的初始序列号y
(3)客户端收到服务器端返回的SYN+ACK报文后,向服务器端返回一个确认号为y+1、序号为x+1的ACK报文,一个标准的TCP连接完成。而SYN flood在攻击时,首先伪造大量的源IP地址,分别向服务器端发送大量的SYN包,此时服务器端会返回SYN/ACK包,因为源地址是伪造的,所以伪造的IP并不会应答,服务器端没有收到伪造IP的回应,会重试3~5次并且等待一个SYN Time(一般为30秒至2分钟),如果超时则丢弃这个连接。攻击者大量发送这种伪造源地址的SYN 请求,服务器端将会消耗非常多的资源(CPU和内存)来处理这种半连接,同时还要不断地对这些IP进行SYN+ACK重试。最后的结果是服务器无暇理睬正常的连接请求,导致拒绝服务。

应用层DDOS攻击

CC攻击

CC攻击的原理非常简单,就是对一些消耗资源比较大的应用不断发起正常的请求,以达到消耗服务器资源的目的。在Web应用中,查询数据库,读/写硬盘文件等操作,相对都会消耗比较多的资源。配合XSS,在一些流量比较大的网页上添加攻击目标的网页请求,当访问被攻击页面的用户,就会对其进行请求以达到攻击的目的。
使用代理隐藏、不断变化IP一直从而来绕过应用中针对于某一个请求的请求频率做出的限制。

验证码

如果是忽略对用户体验的影响,引用验证码这一手段能够有效地阻止自动化重放的行为。嵌入验证码能够有效防止资源滥用,因为脚本通常无法自动识别出验证码
验证码的验证过程就是将用户提交的验证码明文与服务端的Session里保存的验证码明文进行对比

防御DDOS——增加人机认证

资源耗尽攻击

Slowloris

攻击以极低的速度往服务器发送http请求,由于HTTP包头中是以两个CLRF来表示HTTPHeaders部分结束的,所以发一个\r\n后再发一个包头来做到服务器一直等待。

HTTP POST DOS

在发送HTTP POST包时,指定一个非常大的Content-Length值,然后以极低的速度发送数据包,比如10-100s发送一个字节,然后导致服务器一直不断开连接

Server Limit DOSWeb Server

对于HTTP包头都有长度限制,比如Apache默认是8192字节。若攻击者通过XSS攻击,往客户端写了一个超长的Cookie,那么就会导致WebServer默认会认为这是一个超长的非正常请求,导致客户端的拒绝服务。


第十四章 PHP安全


文件包含漏洞

使用方法

include()
require()
include_once()
require_once()

<?php include($_GET[test]);?> #这意味着引用同目录下的test变量文件为php代码

原理

使用了这四个函数去包含一个新文件时,这个文件都会以PHP代码进行执行,PHP内核并不会在意该被包含的文件是什么类型。所以如果被包含的是txt文件、jpg文件、远程url,也都会当成PHP进行执行

远程文件包含

如果php配置文件的allow_url_include为ON则include/require

文件包含使用方法

记一次文件包含

远程文件包含使用方法

记一次远程文件包含

变量覆盖漏洞

当php.ini的register_globals=on时会出现PHP中的代码变量会被cookie、表单中的变量赋值的情况

实现

记一次变量覆盖漏洞


第十五章 Web Server配置安全


Apache安全

默认启动的Module出现的高危漏洞非常少,大多数的高危漏洞集中在默认没有安装或enable的Module上
因此,检查Apache安全的第一件事情就是检查Apache的Module安装情况,根据“最小权限原则”,应该尽可能地减少不必要的Module,对于要使用的Module,则检查其对应版本是否已经存在已知的安全漏洞。

使用root或者是admin权限运行Apache的结果可能是灾难性的

黑客入侵Web成功时,直接获得高权限的Shell
应用程序将获得高权限,如果出现bug时会导致可能会删除本地文件、杀死进程等不可预知的结果
保护好Apache Log

Nginx安全

Nginx的配置非常灵活,在对抗DDOS和CC攻击方面也能得到一定的缓和


第四篇 互联网公司安全运营


第十六章 互联网业务安全


安全开发流程,能够帮助企业以最小的成本提高产品的安全性,它符合“Secure at the source”的战略思想。实施好安全开发流程,对企业安全的发展来说,可以起到事半功倍的效果。

产品需要什么样的安全

安全是产品的一个组成部分。一个好的产品,在设计之初就应该考虑是否会出现安全隐患,从而提前准备好相应的策略。

什么是好的安全方案

对于认证,最基本的选择就是用户名和密码认证,在一些敏感系统会进行双因素认证。比如网上银行办理的“U盾”、“动态口令”、“令牌”“手机短信验证码”等。然而,这些例如手机验证码加用户名密码的认证手段会降低用户体验,“U盾”、“令牌”的制作成本较高。
安全是产品的特性,如果产品能够潜移默化地培养用户的安全习惯,将用户往安全的行为上进行引导,那么这样的安全就是最理想的产品安全。

业务逻辑安全

通过账户绑定使得一个账户被盗导致另一个绑定的账户也一起被盗
密码错误多少次以后锁定账户,可能会被恶意攻击者恶意攻击导致密码错误锁定
审核过的消息进行更改不需要重新审核导致瞒天过海

邮箱钓鱼

对邮件进行签名


第十七章 安全开发流程


需求分析与设计

开发阶段

提供安全的函数
代码安全审计

测试阶段

XSS、SQL注入、PHP FILE INCLUDE可以使用自动化工具检测,而CSRF、越权访问、文件上传需要手工进行检测


第十八章 安全运营


安全监测

入侵检测

紧急响应


脑图


白帽子讲web安全(精写含思维导图)相关推荐

  1. 读《白帽子讲Web安全》之客户端脚本安全(一)

    2019独角兽企业重金招聘Python工程师标准>>> [第2章  浏览器安全] 1.同源策略(Same Origin Policy)是一种约定,它是浏览器最核心也最基本的安全功能. ...

  2. 读白帽子讲WEB安全,摘要

    读<白帽子讲WEB安全>摘要 文章目录 我的安全世界观 安全三要素-CIA 如何实施安全评估 白帽子兵法 客户端安全 浏览器安全 同源策略 浏览器沙箱 恶意网址拦截 高速发展的浏览器安全 ...

  3. 白帽子讲web安全之 浏览器安全

    白帽子讲web安全之 浏览器安全 (一些内容属于个人理解,如有错误请不吝指正) 同源策略 概念 所谓同源,一般是指域名.协议.端口相同.一般来说,只有同源的页面可以互相读取彼此的数据,或者改变彼此在浏 ...

  4. 白帽子讲WEB安全读书笔记(慢慢更新)

    道哥写的白帽子讲WEB安全的读书笔记 文章目录 2020.3.23 ◆ 前言 ◆ 第一篇 世界观安全 1.1 Web安全简史 >> 1.1.1 中国黑客简史 >> 1.1.2 ...

  5. 《白帽子讲Web安全》读后感 —— 对道哥的致敬

    <白帽子讲Web安全>读后感 --Deep Blue (一个安全小兵的感受) 这是一篇作业:这是一篇读后感:这是一篇记录安全的感悟:这是一篇对道哥的敬仰:这是我安全启蒙的钥匙...... ...

  6. 《白帽子讲Web安全 -- 纪念版 吴翰清著》读后随笔

    <白帽子讲Web安全 – 纪念版 吴翰清著> 该书大多数内容举例大多数是2010年左右的 相隔11年左右, 但是内容并没有被淘汰, 感觉很适合入门, 因为内容详细且比较基础 当然, 这只是 ...

  7. 初出牛犊的站长读《白帽子讲web安全》有感

    初出牛犊的站长读<白帽子讲web安全>有感 一.前言--一百个读者的心目中有一百个哈姆雷特 前言的作者经历,会是每个初初恋上计算机的学生碰到的事.曾记得当时候,我第一次接触病毒是在初中的科 ...

  8. 白帽子讲Web安全(纪念版)

    作者:吴翰清 出版社: 电子工业出版社 品牌:博文视点 出版时间:2021-05-01 白帽子讲Web安全(纪念版)

  9. 白帽子讲web安全——认证与会话管理

    在看白帽子讲web安全,刚好看到认证与会话管理:也就是我们在平常渗透测试中遇到最多的登录页面,也即是用户名和密码认证方式,这是最常见的认证方式. 了解两个概念:认证和授权 1):认证的目的是为了认出用 ...

  10. 白帽子讲web安全 ——读书笔记:术语和理论

    最近心血来潮,对安全这些略感兴趣,就买了本 白帽子讲web安全 看看 ,这里做个读书笔记吧!方便啥时候忘了再看一下. exploit--漏洞利用代码 Script kids --脚本小子,利用expl ...

最新文章

  1. 微信小程序canvas绘制环形图(含动画)
  2. UML类图关系表示方法
  3. UVA - 11059 Maximum Product-暴力枚举
  4. [小技巧][JAVA]判断字符串某一位是否是数字/字母
  5. 计算机组成原理双端口存储器实验,计算机组成原理双端口存储器实验报告.doc...
  6. CV新赛事|常见天气分类
  7. Entity Framework 全面教程详解
  8. 【numpy】数组增加一维(升维)小结
  9. error C2065: “SHELLEXECUTEINFO”: 未声明的标识符
  10. puzzle(010.1)自我指涉的选择题
  11. 【技术】客服服务开发
  12. Python beautiful soup解析html获得数据
  13. ceph存储 FC HBA、iSCSI HBA、以太网卡3者区别
  14. 图像的阈值分割(Optimum Thresholding)
  15. Swing中如何实现二级联动下拉列表
  16. 萨满祭司专业技能100%全分析
  17. 计算机事业单位结构化面试的专业题,事业单位结构化面试出题规律:组织活动类问题...
  18. ggplot2-一页多图(不同来源, 灵活绘制)
  19. JAVA与西门子S7 PLC通信,方式一:S7connector
  20. 内网后渗透,生成免杀后门!!

热门文章

  1. H264的RBSP类型之AUD
  2. MATLAB聚类分析源代码
  3. 代码开源为黑客敞开了大门
  4. PHPcmsv9采集-PHPcmsv9免费采集-PHPcmsv9自动采集
  5. android课程设计闹钟,EDA课程设计---数字时钟(闹钟)
  6. kali linux安装谷歌拼音输入法(亲测可用)
  7. DynamipsGUI 模拟pix防火墙
  8. 【2017百度之星资格赛】1004.度度熊的午饭时光思路及代码
  9. android移动应用开发实践教程,分享一些行业经验,成功入职阿里
  10. xp怎么看计算机是多少位的,WinXP系统怎么看电脑是32位还是64位?