丰禾+

个人学习博客分享

0%

Web安全

发表于

1.CIA三元组知道吗？

  • 机密性（Confidentiality）
  • 完整性（Integrity）
  • 可用性（Availability）

2. XSS攻击是如何产生的？

黑客在你的浏览器中插入一段恶意 JavaScript 脚本，窃取你的隐私信息、冒充你的身份进行操作。这就是 XSS 攻击(Cross-Site Scripting，跨站脚本攻击)

因为浏览器无法区分脚本是被恶意注入的还是正常的内容，它都会执行，况且 HTML 非常灵活，可以在任何时候对它进行修改。

3.知道XSS有哪几种类型吗？

  • 反射型 XSS (也叫非持久型)
  • 基于 DOM 的 XSS
  • 存储型 XSS (也叫持久型 XSS)

4.反射型 XSS实现原理

顾名思义，恶意 JavaScript 脚本属于用户发送给网站请求中的一部分，随后网站又将这部分返回给用户，恶意脚本在页面中被执行。一般发生在前后端一体的应用中，服务端逻辑会改变最终的网页代码。

5.DOM型实现原理

目前更流行前后端分离的项目，反射型 XSS 无用武之地。

但这种攻击不需要经过服务器，我们知道，网页本身的 JavaScript 也是可以改变 HTML 的，黑客正是利用这一点来实现插入恶意脚本。

6.存储型实现原理

又叫持久型 XSS，顾名思义，黑客将恶意 JavaScript 脚本长期保存在服务端数据库中，用户一旦访问相关页面数据，恶意脚本就会被执行。常见于搜索、微博、社区贴吧评论等。

7.说下3者的区别

反射型的 XSS 的恶意脚本存在 URL 里，存储型 XSS 的恶意代码存在数据库里。

而基于DOM型的XSS 攻击中，取出和执行恶意代码由浏览器端完成，属于前端 JavaScript 自身的安全漏洞，其他两种 XSS 都属于服务端的安全漏洞。

反射型

image-20210622131957034

基于DOM型

img

存储型

img

8.黑客可以通过XSS攻击做哪些事儿？

  • 盗取用户 Cookie
  • 未授权操作
  • 修改 DOM
  • 刷浮窗广告
  • 发动 XSS 蠕虫攻击
  • 劫持用户行为，进一步渗透内网

9.XSS攻击如何进行防护？

  • 一切用户输入皆不可信，在输出时进行验证
  • 将 HTML 元素内容、属性以及 URL 请求参数、CSS 值进行编码
  • 当编码影响业务时，使用白名单规则进行检测和过滤
  • 使用 W3C 提出的 CSP (Content Security Policy，内容安全策略)，定义域名白名单
  • 设置 Cookie 的 HttpOnly 属性

10.知道哪些XSS攻击案例简单说一下

  • 2005年，年仅19岁的 Samy Kamkar 发起了对 MySpace.com 的 XSS Worm 攻击。

Samy Kamkar 的蠕虫在短短几小时内就感染了100万用户——它在每个用户的自我简介后边加了一句话：“but most of all, Samy is my hero.”（Samy是我的偶像）。这是 Web 安全史上第一个重量级的 XSS Worm，具有里程碑意义。

  • 2007年12月，百度空间收到蠕虫攻击，用户之间开始转发垃圾短消息。
  • QQ 邮箱 m.exmail.qq.com 域名被发现反射型 XSS 漏洞
  • 2011年新浪微博曾被黑客 XSS 攻击，黑客诱导用户点击一个带有诱惑性的链接，便会自动发送一条带有同样诱惑性链接微博。攻击范围层层扩大，也是一种蠕虫攻击。

11.什么是CSRF攻击？

CSRF 英文全称是 Cross-site request forgery，又称为“跨站请求伪造”。

顾名思义，CSRF 攻击就是黑客引诱用户打开黑客的网站，利用用户的登陆状态发起跨站请求。

降维解释：攻击者诱导受害者进入第三方网站，在第三方网站中，向被攻击网站发送跨站请求。

利用受害者在被攻击网站已经获取的注册凭证，绕过后台的用户验证， 达到冒充用户对被攻击的网站执行某项操作的目的。

12.CSRF攻击一般怎么实现？

  • 最容易实现的是 Get 请求，一般进入黑客网站后，可以通过设置 img的 src 属性来自动发起请求
  • 在黑客的网站中，构造隐藏表单来自动发起 Post 请求
  • 通过引诱链接诱惑用户点击触发请求，利用 a 标签的 href。

13.CSRF攻击和XSS攻击有什么区别？

CSRF 攻击不需要将恶意代码注入用户的页面，仅仅是利用服务器的漏洞和用户的登录状态来实施攻击。

CSRF 攻击成本也比 XSS 低，用户每天都要访问大量网页，无法确认每一个网页的合法性，

从用户角度来说，无法彻底防止 CSRF 攻击。

14.那应该如何防范CSRF攻击？

  • 针对实际情况，设置关键 Cookie 的 SameSite 属性为 Strict 或 Lax
  • 服务端验证请求来源站点(Referer、Origin)
  • 使用 CSRF Token，服务端随机生成返回给浏览器的 Token，每一次请求都会携带不同的 CSRF Token
  • 加入二次验证(独立的支付密码)

15.字符集处理过程中可能出现的安全问题有哪些？

  1. 上下层使用的字符集不一致，导致数据的意义出现问题
  2. 处理多字节字符集时出现问题
  3. 对于非法数据的处理上理解不一致
  4. 某些字符集的天生缺陷
  5. 数据库里的校对规则（前后使用字符集不一致就出现问题）

16.如何测试网站是否存在跨站点脚本漏洞？

关键字：Web到目前为止，对于跨站点脚本攻击具有很大的威胁这一点大家并无异议。如果您很精通 XSS 并且只想看看有什么好的测试方法可供借鉴，那么请直接跳到本文的测试部分。如果您对此一无所知，请按顺序认真阅读！如果某个怀有恶意的人（攻击者）可以强迫某个不知情的用户（受害者）运行攻击者选择的客户端脚本，那么便会发生跨站点脚本攻击。“跨站点脚本”这个词应该属于用词不当的情况，因为它不仅与脚本有关，而且它甚至不一定是跨站点的。所以，它就是一个在发现这种攻击时起的一个名字，并且一直沿用至今。从现在开始，我们将使用它常见的缩写名称“XSS”。

XSS 攻击的过程涉及以下三方：

? 攻击者

? 受害者

? 存在漏洞的网站（攻击者可以使用它对受害者采取行动）

​ 在这三方之中，只有受害者会实际运行攻击者的代码。网站仅仅是发起攻击的一个载体，一般不会受到影响。可以用多种方式发起 XSS 攻击。例如，攻击者可通过电子邮件、IM 或其他途径向受害者发送一个经过经心构造的恶意 URL。当受害者在 Web 浏览器中打开该 URL 的时侯，网站会显示一个页面并在受害者的计算机上执行脚本。

XSS 漏洞是什么样的呢？

​ 作为一名 Web 开发人员或测试人员，您肯定知道 Web 应用程序的技术基础是由 HTTP 和 HTML 组成的。HTTP 协议是 HTML 的传输机制，可使用代码设计 Web 页面布局和生成页面。

​ 如果 Web 应用程序接受用户通过 HTTP 请求（如 GET 或 POST）提交的输入信息，然后使用输出 HTML 代码在某些地方显示这些信息，便可能存在 XSS 漏洞。下面是一个最简单的例子：

1.Web 请求如下所示：

GET http://www.somesite.com/page.asp?pageid=10&lang=en&title=Section%20Title

2. 在发出请求后，服务器返回的 HTML 内容包括：Section Title

可以看到，传递给“title”查询字符串参数的用户输入可能被保存在一个字符串变量中并且由 Web 应用程序插入到标记中。通过提供输入内容，攻击者可以控制 HTML。

3.现在，如果站点没有在服务器端对用户输入加以过滤（因为总是可以绕过客户端控件），那么恶意用户便可以使用许多手段对此漏洞加以滥用：

攻击者可以通过摆脱标记来注入代码：

http://www.somesite.com/page.asp?pageid=10&lang=en&title=Section%20Title

< SCRIPT>alert(‘XSS%20attack’)< /SCRIPT>

这个请求的 HTML 输出将为：Section Title

< SCRIPT>alert(‘XSS attack’)< /SCRIPT>

即便是这个最简单的例子，攻击者也可以利用此连接完成数不清的事情。让我们看看会有哪些潜在的威胁，然后讨论一些更高级的测试方法。

XSS 攻击的威胁有多么严重？

​ 由于能够在生成的 Web 页面中注入代码，能想到的威胁有多么严重，就可以有多么严重的威胁。攻击者可以使用 XSS 漏洞窃取 Cookie，劫持帐户，执行 ActiveX，执行 Flash 内容，强迫您下载软件，或者是对硬盘和数据采取操作。

​ 只要您点击了某些 URL，这一切便有可能发生。每天之中，在阅读来自留言板或新闻组的受信任的电子邮件的时侯，您会多少次地单击其中的 URL？

​ 网络钓鱼攻击通常利用 XSS 漏洞来装扮成合法站点。可以看到很多这样的情况，比如您的银行给你发来了一封电子邮件，向您告知对您的帐户进行了一些修改并诱使您点击某些超链接。如果仔细观察这些 URL，它们实际上可能利用了银行网站中存在的漏洞，它们的形式类似于 http://mybank.com/somepage?redirect= < SCRIPT>alert(‘XSS’)< /SCRIPT> ，这里利用了“redirect”参数来执行攻击。

​ 如果您足够狡猾的话，可以将管理员定为攻击目标，您可以发送一封具有如下主题的邮件：“求救！这个网站地址总是出现错误！”在管理员打开该 URL 后，便可以执行许多恶意操作，例如窃取他（或她）的凭证。

​ 好了，现在我们已经理解了它的危害性 — 危害用户，危害管理员，给公司带来坏的公共形象。现在，让我们看看本文的重点 — 测试您的网站是否存在这些问题。

测试 XSS 漏洞

​ 多年以来，我一直是一名全职的安全顾问，已经做过无数次的这种测试了。我将好的测试计划归结为两个字：彻底。对于你我来说，查找这些漏洞与能够有机会在 Bugtraq 或 Vulnwatch 上吹嘘一番没有任何关系；它只与如何出色完成负责的工作有关。如果这意味着对应用程序中所有的单个查询字符串参数、cookie 值 以及 POST 数据值进行检查，那么这只能表明我们的工作还不算太艰巨。

​ 显然，一次完整的安全性检查所涉及的内容通常远远超出寻找 XSS 漏洞那样简单；它需要建立整体的威胁模型，测试溢出漏洞、信息泄漏、错误处理、SQL 注入、身份验证和授权错误。好在执行这样彻底的工作时，各个领域之间都存在重叠。比如，在测试 XSS 漏洞时，经常会同时找出错误处理或信息泄漏问题。

​ 我假设您属于某个负责对 Web 应用程序进行开发和测试的小组。在这个幸运的位置上，您可以混合使用黑盒和白盒方法。每种方法都有它自己的优点，结合使用时甚至能相互提供支持。

​ \1. 按顺序准备您的工具包

​ 测试工作也可以是自动化的，但是我们在这里只讨论手动操作。手动测试的必备工具包括：

? Paros proxy (http://www.parosproxy.org)，用于截获 HTTP 通信数据

? Fiddler (http://www.fiddlertool.com/fiddler)，用于截获 HTTP 通信数据

? Burp proxy (http://www.portswigger.net/proxy/)

? TamperIE (http://www.bayden.com/dl/TamperIESetup.exe)，用于修改 GET 和 POST

​ 我们以上至少列出了三种 Web 代理软件。也可以寻找其他不同的类似产品，因为每种产品都有它自己的独到之处。下面，您需要在 Web 浏览器发出 HTTP 请求之前截获这些请求，并修改它们以注入 XSS 测试代码。上面所有这些工具都可以完成这项任务，某些工具还会显示返回的 HTML 源代码（如果您选择了截获服务器响应）。

​ 截获客户端发出的 GET 和 POST 请求非常重要。这样可以绕过所有的客户端 javascript 输入验证代码。我在这里要提醒所有 Web 开发人员 — 客户端安全控制是靠不住的。应该总是在服务器端执行有效性验证。

​ \2. 确定站点及其功能 — 与开发人员和 PM 交流

​ 绘制一些简单的数据流图表，对站点上的页面及其功能进行描述。此时，可以安排一些与开发人员和项目经理的会议来建立威胁模型。在会议上尽可能对应用程序进行深入探讨。站点公开了 Web 服务吗？是否有身份验证表单？有留言板吗？有用户设置页面吗？确保列出了所有这些页面。

​ \3. 找出并列出所有由用户提供输入的点

​ 对站点地图进行进一步细化。我通常会为此创建一个电子表格。对于每个页面，列出所有查询字符串参数、cookie 值、自定义 HTTP 标头、POST 数据值和以其他形式传递的用户输入。不要忘记搜索 Web 服务和类似的 SOAP 请求，并找出所有允许用户输入的字段。

​ 分别列出每个输入参数，因为下面需要独立测试每个参数。这可能是最重要的一个步骤！如果阅读下面的电子表格，您会看到我已经在示例站点中找出了一大堆这样的东西。如 forwardURL 和 lang 这样的查询字符串。如 name、password、msgBody、msgTitle 和这样的 POST 数据，甚至某些 Cookie 值。所有这些都是我们感兴趣的重要测试内容。

​ \4. 认真思考并列出测试用例

​ 使用已经得到的电子表格并列出各种用来测试 XSS 漏洞的方法。我们稍候将讨论各种方法，但是现在先让我们看看我的电子表格的屏幕截图，请注意，我列出了页面上允许的每个值以及每个值的所有测试类型。这种记录测试的方法仅是我自己的习惯，您可以使用自己的方法。我喜欢记录所有东西，以便我能知道已经做了哪些工作和哪些工作没有做。

​ \5. 开始测试并注意输出结果

​ 在查找漏洞的过程中，最重要的部分并不是您是否找到了漏洞。而是您是否真正知道究竟发生了哪些事情。对于 XSS，只需检查 HTML 输出并看看您输入的内容在什么地方。它在一个 HREF 标记中吗？是否在 IFRAME 标记中？它在 CLSID 标记中吗？在 IMG SRC 中吗？某些 Flash 内容的 PARAM NAME 是怎样的？

​ 我会检查所有这些情况，如果您对所输入内容的目的十分了解，可以调整您的测试来找出问题。这意味着您可能需要添加一个额外的封闭括号“>”来让某个标记变得完整，或者添加一个双引号来关闭标记内的一个元素。或者，您可能需要使用 URL 或 HTML 来编码您的字符，例如将双引号变为 %22 或 。

​ 嗯，并不那么容易，这个站点看来防范比较严密。现在该怎么办呢？

​ 那么，也许您的简单测试用例 < SCRIPT>alert(‘hi’)< /SCRIPT> 并不能产生期望中的警告对话框。仔细想想这个问题并在可能的情况下与开发人员进行交流。也许他们对输入中的尖括号、单引号或圆括号进行了过滤。也许他们会过滤“script”这个词。重新研究为何输入会产生这样的输出，并理解每个值（查询字符串、cookie、POST 数据）的作用。“pageId=10”这样的查询字符串值可能对输出没有影响，因此不值得花费时间测试它。有时，最好试着注入单个字符（例如尖括号、双引号标记或者圆括号），看看应用程序是否过滤这些字符。然后，便可以知道您面对的过滤级别究竟如何。接着，可以调整测试方法，对这些字符进行编码并重试，或者寻找其他注入办法。

改变测试用例

​ 我恐怕无法充分对此进行说明：研究输入的值会输出什么样的 HTML 页面非常重要。如果它们不能产生输出，那么不要在它们上面浪费时间。如果可以，请进行研究，因为您需要根据输出对测试进行相应的修改。我使用了各种变化形式来找出能接受和显示脚本代码的参数。因为这涉及太多内容，因此在这里无法一一进行讨论，但是请务必注意以下几种情况：

​ 有许多变化形式可以尝试。关键在于了解程序究竟使用何种方式处理输入和显示输出页面。如同这些例子所展示的，常见的变化形式经常是在脚本代码前面加上 “>””，以尝试封闭网站可能在输出中生成的标记。还可以对代码进行 URL 编码，尝试绕过服务器端的输入过滤功能。此外，因为尖括号“<>”通常会在输入时被过滤和从输出中删除，所以还必须尝试不需要尖括号的 XSS，例如 ”&{alert(XSS)};”

持久和动态

​ 找出一个成功的 XSS 颇费周折，因为在开始时 XSS 攻击可能并不是那么显而易见的。随便举一个例子，如果向网站添加一条新留言并在“msgTitle”值中注入代码，在提交数据后，您可能不会立即看到脚本代码被执行。但是，当您访问留言板的时侯，将会在 HTML 页面中使用“msgTitle”值并将其作为脚本代码执行。这种情况被称作持久性 XSS 攻击，如果包含脚本代码的值将被保存到客户端或者后端系统并在稍候的时间被执行，便会发生此种攻击。

​ 而与此相对的是动态 XSS 攻击，这种攻击会立即执行并只发生一次。比如，如果某个链接或 GET 请求在某个用来控制页面输出的查询字符串中包含了脚本代码，那么在点击链接后会立即显示输出。

17.在网站测试中应该如何进行安全性测试？

安全性测试（security testing）是有关验证应用程序的安全服务和识别潜在安全性缺陷的过程。

　　注意：安全性测试并不最终证明应用程序是安全的，而是用于验证所设立策略的有效性，这些对策是基于威胁分析阶段所做的假设而选择的。

　　以下是我读<<软件评测试教程>>中的Web安全性测试章节内容，并进行修改的笔记，前面看了好多朋友写的，不过不是很全，希望对大家有所帮助，建议大家还是买本<<软件评测试教程>>此书绝对物超所值^_^

WEB安全性测试

　　一个完整的WEB安全性测试可以从部署与基础结构、输入验证、身份验证、授权、配置管理、敏感数据、会话管理、加密。参数操作、异常管理、审核和日志记录等几个方面入手。

\1. 安全体系测试

  1. 部署与基础结构

　　网络是否提供了安全的通信

　　部署拓扑结构是否包括内部的防火墙

　　部署拓扑结构中是否包括远程应用程序服务器

　　基础结构安全性需求的限制是什么

　　目标环境支持怎样的信任级别

  1. 输入验证

l 如何验证输入

A. 是否清楚入口点

B. 是否清楚信任边界

C. 是否验证Web页输入

D. 是否对传递到组件或Web服务的参数进行验证

E. 是否验证从数据库中检索的数据

F. 是否将方法集中起来

G. 是否依赖客户端的验证

H. 应用程序是否易受SQL注入攻击

I. 应用程序是否易受XSS攻击

l 如何处理输入

  1. 身份验证

　　是否区分公共访问和受限访问

　　是否明确服务帐户要求

　　如何验证调用者身份

　　如何验证数据库的身份

　　是否强制试用帐户管理措施

  1. 授权

　　如何向最终用户授权

　　如何在数据库中授权应用程序

　　如何将访问限定于系统级资源

  1. 配置管理

　　是否支持远程管理

　　是否保证配置存储的安全

　　是否隔离管理员特权

  1. 敏感数据

　　是否存储机密信息

　　如何存储敏感数据

　　是否在网络中传递敏感数据

　　是否记录敏感数据

  1. 会话管理

　　如何交换会话标识符

　　是否限制会话生存期

　　如何确保会话存储状态的安全

  1. 加密

　　为何使用特定的算法

　　如何确保加密密钥的安全性

  1. 参数操作

　　是否验证所有的输入参数

　　是否在参数过程中传递敏感数据

　　是否为了安全问题而使用HTTP头数据

  1. 异常管理

　　是否使用结构化的异常处理

　　是否向客户端公开了太多的信息

  1. 审核和日志记录

　　是否明确了要审核的活动

　　是否考虑如何流动原始调用这身份

\2. 应用及传输安全

　　WEB应用系统的安全性从使用角度可以分为应用级的安全与传输级的安全，安全性测试也可以从这两方面入手。

　　应用级的安全测试的主要目的是查找Web系统自身程序设计中存在的安全隐患，主要测试区域如下。

　　注册与登陆：现在的Web应用系统基本采用先注册，后登录的方式。

A. 必须测试有效和无效的用户名和密码

B. 要注意是否存在大小写敏感，

C. 可以尝试多少次的限制

D. 是否可以不登录而直接浏览某个页面等。

　　在线超时：Web应用系统是否有超时的限制，也就是说，用户登陆一定时间内（例如15分钟）没有点击任何页面，是否需要重新登陆才能正常使用。

　　操作留痕：为了保证Web应用系统的安全性，日志文件是至关重要的。需要测试相关信息是否写进入了日志文件，是否可追踪。

　　备份与恢复：为了防范系统的意外崩溃造成的数据丢失，备份与恢复手段是一个Web系统的必备功能。备份与恢复根据Web系统对安全性的要求可以采用多种手段，如数据库增量备份、数据库完全备份、系统完全备份等。出于更高的安全性要求，某些实时系统经常会采用双机热备或多级热备。除了对于这些备份与恢复方式进行验证测试以外，还要评估这种备份与恢复方式是否满足Web系统的安全性需求。

　　传输级的安全测试是考虑到Web系统的传输的特殊性，重点测试数据经客户端传送到服务器端可能存在的安全漏洞，以及服务器防范非法访问的能力。一般测试项目包括以下几个方面。

　　HTTPS和SSL测试：默认的情况下，安全HTTP（Soure HTTP）通过安全套接字SSL（Source Socket Layer）协议在端口443上使用普通的HTTP。HTTPS使用的公共密钥的加密长度决定的HTTPS的安全级别，但从某种意义上来说，安全性的保证是以损失性能为代价的。除了还要测试加密是否正确，检查信息的完整性和确认HTTPS的安全级别外，还要注意在此安全级别下，其性能是否达到要求。

　　服务器端的脚本漏洞检查：存在于服务器端的脚本常常构成安全漏洞，这些漏洞又往往被黑客利用。所以，还要测试没有经过授权，就不能在服务器端放置和编辑脚本的问题。

　　防火墙测试：防火墙是一种主要用于防护非法访问的路由器，在Web系统中是很常用的一种安全系统。防火墙测试是一个很大很专业的课题。这里所涉及的只是对防火墙功能、设置进行测试，以判断本Web系统的安全需求。

另推荐安全性测试工具：

　　Watchfire AppScan：商业网页漏洞扫描器(此工具好像被IBM收购了，所以推荐在第一位)

　　AppScan按照应用程序开发生命周期进行安全测试，早在开发阶段就进行单元测试和安全保证。Appscan能够扫描多种常见漏洞，例如跨网站脚本、HTTP应答切开、参数篡改、隐藏值篡改、后门/调试选项和缓冲区溢出等等。

　　Acunetix Web Vulnerability Scanner：商业漏洞扫描器(目前用的比较多，不过这东东N占内存)

Acunetix WVS自动检查您的网页程序漏洞，例如SQL注入、跨网站脚本和验证页面弱密码破解。Acunetix WVS有着非常友好的用户界面，还可以生成个性化的网站安全评估报告。

18.Web应用攻击中目录遍历攻击的方法及如何预防？

对于一个安全的Web服务器来说，对Web内容进行恰当的访问控制是极为关键的。目录遍历是Http所存在的一个安全漏洞，它使得攻击者能够访问受限制的目录，并在Web服务器的根目录以外执行命令。

　　Web服务器主要提供两个级别的安全机制：

　　访问控制列表——就是我们常说的ACL 　　根目录访问

　　访问控制列表是用于授权过程的，它是一个Web服务器的管理员用来说明什么用户或用户组能够在服务器上访问、修改和执行某些文件的列表，同时也包含了其他的一些访问权限内容。

　　根目录是服务器文件系统中一个特定目录，它往往是一个限制，用户无法访问位于这个目录之上的任何内容。

　　例如：在Windows的IIS其默认的根目录是C:\Inetpub\wwwroot，那么用户一旦通过了ACL的检查，就可以访问C:\Inetpub\wwwroot\news目录以及其他位于这个根目录以下的所有目录和文件，但无法访问C:\Windows目录。

　　根目录的存在能够防止用户访问服务器上的一些关键性文件，譬如在Windows平台上的cmd.exe或是Linux/Unix平台上的口令文件。

　　这个漏洞可能存在于Web服务器软件本身，也可能存在于Web应用程序的代码之中。

　　要执行一个目录遍历攻击，攻击者所需要的只是一个web浏览器，并且有一些关于系统的一些缺省文件和目录所存在的位置的知识即可。

　　如果你的站点存在这个漏洞，攻击者可以用它来做些什么?

　　利用这个漏洞，攻击者能够走出服务器的根目录，从而访问到文件系统的其他部分，譬如攻击者就能够看到一些受限制的文件，或者更危险的，攻击者能够执行一些造成整个系统崩溃的指令。

　　依赖于web站点的访问是如何设置的，攻击者能够仿冒成站点的其他用户来执行操作，而这就依赖系统对Web站点的用户是如何授权的。

　　利用Web应用代码进行目录遍历攻击的实例

　　在包含动态页面的Web应用中，输入往往是通过GET或是POST的请求方法从浏览器获得，以下是一个GET的Http URL请求示例：

　　http://test.webarticles.com/show.asp?view=oldarchive.html

　　利用这个URL，浏览器向服务器发送了对动态页面show.asp的请求，并且伴有值为oldarchive.html的view参数，当请求在Web服务器端执行时，show.asp会从服务器的文件系统中取得oldarchive.html文件，并将其返回给客户端的浏览器，那么攻击者就可以假定show.asp能够从文件系统中获取文件并编制如下的URL：

　　http://test.webarticles.com/show.asp?view=../../../../../Windows/system.ini

　　那么，这就能够从文件系统中获取system.ini文件并返回给用户，../的含义这里就不用多说了，相信大家都会明白。攻击者不得不去猜测需要往上多少层才能找到Windows目录，但可想而知，这其实并不困难，经过若干次的尝试后总会找到的。

　利用Web服务器进行目录遍历攻击的实例：

　　除了Web应用的代码以外，Web服务器本身也有可能无法抵御目录遍历攻击。这有可能存在于Web服务器软件或是一些存放在服务器上的示例脚本中。

　　在最近的Web服务器软件中，这个问题已经得到了解决，但是在网上的很多Web服务器仍然使用着老版本的IIS和Apache，而它们则可能仍然无法抵御这类攻击。即使你使用了已经解决了这个漏洞的版本的Web服务器软件，你仍然可能会有一些对黑客来说是很明显的存有敏感缺省脚本的目录。

　　例如，如下的一个URL请求，它使用了IIS的脚本目录来移动目录并执行指令：http://server.com/scripts/..%5c../Windows/System32/cmd.exe?/c dir c:\

　　这个请求会返回C:\目录下所有文件的列表，它使通过调用cmd.exe然后再用dir c:\来实现的，%5c是web服务器的转换符，用来代表一些常见字符，这里表示的是“\”

　　新版本的Web服务器软件会检查这些转换符并限制它们通过，但对于一些老版本的服务器软件仍然存在这个问题。

　　如何判断是否存在目录遍历漏洞?

　　最好的方式就是使用Web漏洞扫描器，Web漏洞扫描器能够遍历你Web站点的所有目录以判断是否存在目录遍历漏洞，如果有它会报告该漏洞并给出解决的方法，除了目录遍历漏洞以外，Web应用扫描还能检查SQL注入、跨站点脚本攻击以及其他的漏洞。

19.介绍一下DDoS攻击新中的反弹技术

反弹技术就是利用反弹服务器实现攻击的技术。
所谓反弹服务器(Reflector)是指当收到一个请求数据报后就会产生一个回应数据报的主机.例如,所有的Web服务器,DNS服务器和路由服务器都是反弹服务器.攻击者可以利用这些回应的数据报对目标机器发动DDoS攻击。
反弹技术原理
反弹服务器攻击过程和传统的DDoS攻击过程相似,如前面所述的4个步骤中,只是第4步改为:攻击者锁定大量的可以作为反弹服务器的服务器群,攻击命令发出后,代理守护进程向已锁定的反弹服务器群发送大量的欺骗请求数据包,其原地址为受害服务器或目标服务器.
反弹技术实现DDoS攻击与传统DDoS攻击的区别:
1.反弹技术实现DDoS攻击比传统DDoS攻击更加难以抵御.实际上它的攻击网络结构和传统的相比多了第四层——被锁定的反弹服务器层.反弹服务器的数量可以远比驻有守护进程的代理服务器多,故反弹技术可以使攻击时的洪水流量变弱,最终才在目标机汇合为大量的洪水,其攻击规模也比传统DDoS攻击大得多。
2.目标机更难追查到攻击来源.目标机接收到的攻击数据报的源IP是真实的,反弹服务器追查到的数据报源IP是假的.又由于反弹服务器上收发数据报的流量较小(远小于代理服务器发送的数量),所以,服务器根据网络流量来自动检测是否为DDoS攻击源的这种机制将不起作用。

20.请介绍一下盗号木马和网页木马的原理和机制

盗号木马是指隐秘在电脑中的一种恶意程序，跟灰鸽子不同，这是以盗号为目的并且能够伺机盗取各种需要密码的账户（游戏，应用程序等）的木马病毒。

  • 在传统的远程控制木马基础上发展出的以窃取敏感信息为目标的专用木马。
  • QQ盗号木马:数十款，流行网游:均发现相应的盗号木马
  • 免杀机制：继承可执行程序加壳/变形等技术方法

网页木马就是表面上伪装成普通的网页文件或是将恶意的代码直接插入到正常的网页文件中，当有人访问时，网页木马就会利用对方系统或者浏览器的漏洞自动将配置好的木马的服务端下载到访问者的电脑上来自动执行。

网页木马实际上是一个HTML网页，与其它网页不同的是该网页是黑客精心制作的，用户一旦访问了该网页就会中木马。为什么说是黑客精心制作的呢？因为嵌入在这个网页中的脚本恰如其分地利用了IE浏览器的漏洞，让IE在后台自动下载黑客放置在网络上的木马并运行（安装）这个木马，也就是说，这个网页能下载木马到本地并运行（安装）下载到本地电脑上的木马，整个过程都在后台运行，用户一旦打开这个网页，下载过程和运行（安装）过程就自动开始。

  • 网页木马本质上并非木马，而是Web方式的渗透攻击代码
  • 网页木马一般以JavaScript, VBScript等脚本语言实现
  • 免杀机制：1）通过大小写变换、十六进制编码、unicode编码、base64编码、escape编码等方法对网页木马进行编码混淆 2）通过通用（screnc等）或定制的加密工具（xxtea等）对网页木马进行加密 3）修改网页木马文件掩码、混淆文件结构、分割至多个文件等

参考:

https://developer.51cto.com/art/202006/619575.htm

http://www.100mian.com/category/webanquan/

WechatIMG360