白帽子讲web安全（精写含思维导图） |
您所在的位置：网站首页 › web安全书籍下载 › 白帽子讲web安全（精写含思维导图） |
白帽子讲web安全（精写含思维导图）
|
写在前面
重要的事多说几遍
本文对学习基础、面试、了解安全都有辅助的作用 觉得本文对您有帮助的朋友们，请您动动小手点赞、收藏加关注哦~ 觉得本文对您有帮助的朋友们，请您动动小手点赞、收藏加关注哦~ 觉得本文对您有帮助的朋友们，请您动动小手点赞、收藏加关注哦~ 本文一共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存储型XSSDOM型XSS 3.2 XSS攻击进阶攻击手段 XSS攻击技巧XSS网站设计的防御 第四章 跨站点请求位置（CSRF）攻击手段防御手段验证码Referer CheckTokenCSRF 第五章 点击劫持防御 第六章 HTML5安全HTML 5 新标签iframe的sandboxnoreferer（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保持攻击单点登录 SSOOpenID 第十章 访问控制垂直权限水平权限OauthOAuth 第十一章 加密算法与随机数加密攻击唯密文攻击已知明文攻击选择明文攻击选择密文攻击 密码学里的基本原则伪随机数问题 第十二章 Web框架安全第十三章 应用层拒绝服务攻击定义三次握手的缺陷应用层DDOS攻击CC攻击验证码防御DDOS——增加人机认证资源耗尽攻击SlowlorisHTTP POST DOSServer 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（提升权限）未经授权获得许可 风险分析
针对资产等级划分、威胁分析、风险分析阶段评估出一个合适的解决方案。 1.7 白帽子兵法 Secure By Default 原则制定黑名单、白名单。白名单相较于黑名单来说更安全，但白名单并不是完全安全的，因为安全建立与信任，白名单中若出现不安全的名单那么信任列表将会变得不可信。 最小权限原则授予主体必要的权限，不要过度授权，这样能有效的减少系统、网络、应用、数据库出错的机会。 纵深防御原则从不同层面、不同角度对系统做出整体的解决方案，而不是一个安全方案做两遍或者是多遍（木桶理论）。 在正确的地方做正确的事,防止造成”乌龙“（例如XSS过滤关键字可能会过滤“1”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通过代码加载了b.com上的b.js。因为b.js是运行在a.com上的，所以b.js的域就是a.com。 在浏览器中, 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中进行发送，所以是藏代码的好地方，注意去除第一个#即可。 使用字节拼接注释掉有限制长度的控件。使用标签伪造图片、链接、脚本 使用window.name XSS网站设计的防御HttpOnly：JavaScript禁止访问带有HTTPOnly属性的Cookie。 Apache支持的Header的TRACE能绕过此读取Cookie。输入检查对用户输入的字符进行输入检查，像是、"、"等应该将其进行过滤或者是编码。 输出检查对于不同的情况对用户能输入的字符进行编码HTML代码里插入的话使用HTMLEncode中插入的话使用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能够使、等标签在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的sandboxallow-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 AttackBENCHMARK(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() #这意味着引用同目录下的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、越权访问、文件上传需要手工进行检测 第十八章 安全运营 安全监测 入侵检测 紧急响应 脑图
|
根据风险因素所对应的权重进行相加算出权值将12-15分之间的定义为高威胁。将8-11分之间的定义为中威胁。将0-7分之间的定义为低威胁。
【本文地址】