真的！Web安全入门看这个就够了

第一章 我的世界安全观

1.1 Web安全简史

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

1.2 黑帽子，白帽子

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

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

通过一个安全检查的过程，梳理未知的人或物，将其划分为不同的信任级别的区域，两个不同信任域之间的边界叫做信任边界。

安全问题的本质是信任问题。安全方案的设计基础是建立在信任关系之上的，例如保管文件的“锁”，你得确保锁的工匠是信任的，他没有私自保管一把额外的钥匙；抽屉的工匠失是信任的，他没有给抽屉安装后门；钥匙也需要保管在一个安全不会出现问题的地方。

1.5 安全三要素

机密性

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

完整性

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

可用性

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

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

Web安全入门笔记，需要的小伙伴可以自取！

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。

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=2 或and 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))>64and ascii(substring((select concat(username,0x3a,passwd) from users limit 0,1),1,1))>96and ascii(substring((select concat(username,0x3a,passwd) from users limit 0,1),1,1))>100and 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、越权访问、文件上传需要手工进行检测

第十八章 安全运营

安全监测

入侵检测

紧急响应