[CATARC_2017] 第一周

第一天 (5. 8)

7: 05上班车, 司机走小道, 很颠簸, QAQ 7: 40到了公司, 公司很不错;

上午. 开启动会, 被分配到测试部 [CAMDS系统安全测试组], 领取项目资料;

中午. 吃午饭, 饭后参观公司，看沙盘;

下午. 聆听张部和国哥的要求, 记录公司活动内容, 看牛客网视频: SQL注入 XSS跨站脚本攻击...

 

第二天 (5. 10)

7: 00上班车, 司机像头犟牛, QAQ 第一次到公司吃早餐, 是20元自助; ^_^

上午. 初学AppScan - 配置和使用

Appscan是web应用程序渗透测试舞台上使用最广泛的工具之一.它是一个桌面应用程序，它有助于专业安全人员进行Web应用程序自动化脆弱性评估。支持Ajax和Dojo框架。

探索和测试阶段：

在我们开始扫描之前，让我们对Appscan的工作做一个了解.任何自动化扫描器都有两个目标：找出所有可用的链接和攻击寻找应用程序漏洞。

探索(Explore):

在探索阶段，Appscan试图遍历网站中所有可用的链接，并建立一个层次结构。它发出请求，并根据响应来判断哪里是一个漏洞的影响范围。例如，看到一个登陆页面，它会确定通过绕过注入来通过验证.在探索阶段不执行任何的攻击，只是确定测试方向.这个阶段通过发送的多个请求确定网站的结构和即将测试的漏洞范围。

测试(Test)：

在测试阶段,Appscan通过攻击来测试应用中的漏洞.通过释放出的实际攻击的有效载荷，来确定在探索阶段建立的安全漏洞的情况.并根据风险的严重程度排名。

在测试阶段可能回发现网站的新链接，因此Appscan在探索和测试阶段完成之后会开始另一轮的扫描，并继续重复以上的过程，直到没有新的链接可以测试。扫描的次数也可以在用户的设置中配置.

 

下载AppScan, 扫描 demo.testfire.net (很漫长)；

也可以点击"Create New Scan" 开始扫描一个新的Web应用程序 ->

选择一个适合你要求的扫描模板。模板包括已经定义好的扫描配置.选择一个模板后会出现配置向导。它会问你选择的扫描类型，选择"Web Application Scan"，然后点击Next

扫描配置向导是该工具的核心部分,使用设置向导，会让Appscan知道的需求,其中有很多可供的需求选择.

 

URL and Servers(URL和服务器)

Starting URL(起始网址)：此功能指定要扫描的起始网址.在大多数情况下，这将是该网站的登陆页面.选择http://demo.testfire.NET这个演示站来测试Web应用程序漏洞.如果你想限制只扫描到这个目录下的链接,选中该复选框.

Case Sensitive Path(大小写的选择):如果你的服务器URL有大小写的区别,选择此项。对大小写的区别取决于服务器的操作系统,Linux/Unix中对大小写是敏感的,而Windows是没有的.

Additional Servers and Domains(另外的服务器和域):在扫描过程中Appscan尝试抓取本网站上的所有链接。当它发现了一个链接指向不同的域,它是不会进行扫描攻击的,除非在"Additional Servers and Domains"中有指定.因此,通过指定该标签下的链接,来告诉Appscan继续扫描,即使它和URL是不同的域下.点击下一步继续。

 

Login Management(登陆管理)

在扫描的过程中，可能会不小心碰到退出按钮导致Appscan注销.因此,要登陆到应用程序中,我们需要根据本条中的设置。

Recorded(记录):选择此项后,会出现一个新的浏览器，并尝试链接到指定的网站作为本扫描的起始URL.你需要输入账号和密码登陆到应用程序.这样设置之后你可以关闭浏览器，但是不要点击注销按钮.有时候你会发现打开的浏览器不是IE或者Mozilla，而是Appscan浏览器.你可以改变通过设置来改变这个.Tools-->Options -->Advanced,设置OpenIEBrower的值0--Appscan浏览器,1--IE,2--Firefox,3--Chrome.如果该网站的行为在不同的浏览器下有所不同,这个设置将是非常有用的.

图四

Prompt(提示):每次注销之后,Appscan会提示你登陆到应用程序中.如果你打算整个扫描你的系统，你可以选择这个选项.

Automatic(自动)：在这里你可以直接指定用户名和密码,当你需要登陆到应用程序的时候.

 

Test Policy

根据你的测试策略,你需要选择最适合你需求的策略,现有的策略都是默认的,仅应用和基础设置，侵入性的，完整的，关键的少数等等.其中大多是使用现有的策略.如果你不希望在登陆时发送测试和注销页面，你可以选择该选项。

 

Complete

这是开始扫描的最后一步.IBM Rational Appscan允许你选择你想要的扫描方式，即完成扫描,探索扫描等.

Start a full automatic sacn(开始一个完整的自动扫描):随着前面创建的配置,Appscan将开始探索和测试阶段.

Start with automatic explore only(开始探索扫描):Appscan只会探索应用程序，但不发送攻击.

Start with manual explore(开始手动探索):浏览器将被打开,你可以手动浏览器应用程序.

当你想做出更多的更改扫描配置,你可以选择最后一个选项"i will start scan later".

在我们开始之前,我们有很重要的事情要做,它是Appscan的心脏和灵魂-"Full scan Configuration(全局扫描配置)"窗口.让我们明白为什么它在扫描任意应用程序的时候那么重要.

AppScan渗透测试工具

图七：

Full Scan Configuration

在下图中，有四个主要的部分--探索，链接，测试和一般，让我们看看具体的细节：

Explore

URL and Servers(URL和服务器): 扫描的URL和额外的服务器链接的处理.

Login Management(登陆管理):除了登陆方法,如果你想在Appscan同时登陆，通过这个可以指定.这将减少总的扫描时间.你还可以指定正则表达式检测注销页.

图八：

Environment Definition(环境的定义):在此设置下，你可以指定操作系统,Web服务器,数据库服务器,以及其它第三方组件,它可以帮助你提高扫描的精度和性能。

 

图九：

Exclude Paths and Files(排除路径和文件):设置扫描过程中排除的特定路径,甚至是特定的文件,比如.mps或.7z等.你可以在此选项下通过正则表达式来设置.

Explore Options(浏览选项):冗余路径选项有助于设置Appscan针对相同路径的扫描次数限制。因为有时Appscan可能会进入一个无限循环一次又一次扫描相同的URL.

Parameters and Cookies(参数和Cookies):包括有关参数的详细信息和应用程序中存在的COOKIES.

Automatic Form Fill(自动表格填写):在扫描过程中,Appscan遇到需要输入的形式.例如，一个注册页面，可能需要输入值，比如用户名和地址等。通过选择此项,可以让Appscan自动填写这些信息.

Error pages(错误页面):你在此配置下输入的错误页面将帮助Appscan判断错误页面.

Multi-Step Operations(多步骤操作):有部分应用程序,只有当你请求的数据按一定的顺序才可以达成(比如电子商务网站).通过这个设置你可以点击"start recording"来记录其序列.

Glass box Scanning:Glass box Scanning是Appscan引入的一个新的功能,代理将被安装在服务器上,这有助于扫描找到隐藏的URl和其它的问题.

Communication and Proxy(通讯及代理):你可以指定扫描器是否可以使用IE浏览器的代理设置(或不能使用任何代理)。

HTTP Authentication(HTTP身份验证):使用客户端证书,上传证书文件和密钥文件.

Test Policy(测试策略):所有的测试名称都列在这个部分,如果你不想Appscan扫描特定的漏洞，你可以取消其中的任何一个.

 

图十：

Test Options(测试选项):这个部分你可以选择适合的测试选项.Appscan发送大量的测试，需要花费大量的时间.但是选择适性测验,Appscan会尝试发送,以确定是适当的测试.它可以检测到服务器是IIS,然后只发送其中针对IIS的脆弱性检测测试,而不会检查其它服务器有关的问题.

Privilege Escalation(特权升级):你可以上传不同权限的用户或未经授权的用户扫描的扫描文件。

Scan Expert(扫描专家):扫描专家提出了建议，以更好的扫描应用程序。

点击OK，将回到最初的扫描向导窗口.选择"start a full automatic sacn",单击"finish"。完成配置过程，开始Appscan扫描.下一篇文章中，我们将探讨有关Appscan扫描结果分析.

 

 

 

 

初学AppScan - 分析扫描结果:

 

 

使用AppScan 浏览器

遇到了许多问题

 

如何登陆测试需要用户名密码的站点: 录制

内存不足:

设置: 选项 -> 高级 -> PerformanceMonitor.RestartOnOutOfMemoryBoolean 设置 True，当Appscan出现内存不足的时候，就会重启，重启后会继续测试 QAQ

结果类型

Blind SQL 注入（基于时间）

可能会查看、修改或删除数据库条目和表

 

可能原因

未对用户输入正确执行危险字符清理

技术描述

该软件使用受外部影响的输入来构造 SQL 命令的全部或一部分，但是它未能对可能在 SQL 命令发送到数据库时修改该命令的元素进行无害化处理。如果在用户可控制的输入中没有对 SQL 语法充分地除去或引用，那么生成的 SQL 查询可能会导致将这些输入解释为 SQL 而不是普通用户数据。这可用于修改查询逻辑以绕过安全性检查，或者插入其他用于修改后端数据库的语句，可能包括执行系统命令。

例如，假设有一个带有登录表单的 HTML 页面，该页面最终使用用户输入对数据库运行以下 SQL 查询：

  SELECT * FROM accounts WHERE username='$user' AND password='$pass'

两个变量（$user 和 $pass）包含了用户在登录表单中输入的用户凭证。如果用户输入“jsmith”作为用户名，并输入“Demo1234”作为密码，那么 SQL 查询将如下所示：

  SELECT * FROM accounts WHERE username='jsmith' AND password='Demo1234'

但如果用户输入“'”（单撇号）作为用户名，输入“'”（单撇号）作为密码，那么 SQL 查询将如下所示：

  SELECT * FROM accounts WHERE username=''' AND password='''

当然，这是格式错误的 SQL 查询，并将调用错误消息，而该错误消息可能会在 HTTP 响应中返回。通过此类错误，攻击者会知道 SQL 注入已成功，这样攻击者就会尝试进一步的攻击媒介。SQL 盲注类似于 SQL 注入。不同之处在于，要利用该攻击，攻击者无需寻找响应中的 SQL 错误。因此，AppScan 用于识别该攻击的方法也不同。AppScan 会查找易受 SQL 注入（通过多个请求来操纵应用程序的逻辑，而不是尝试调用 SQL 错误）影响的脚本。

该技巧需要发送特定请求，其中易受攻击的参数（嵌入在 SQL 查询中的参数）进行了相应修改，以便响应中会指示是否在 SQL 查询上下文中使用数据。该修改涉及将 AND 布尔表达式与原始字符串一起使用，使其一时求值为 True，一时求值为 False。在一种情况下，净结果应该与原始结果相同（登录成功），而在另一种情况下，结果应该完全不同（登录失败）。在某些少见的情况下，求值为 True 的 OR 表达式也可能很有用。如果原始数据是数字，可以使用更简单的花招。假设原始数据为 123。此数据可以在一个请求中替换为 0+123，而在另一个请求中替换为 456+123。第一个请求的结果应该与原始结果相同，第二个请求的结果应该不同（因为得出的数字是 579）。在某些情况中，我们仍需要上面所说明的攻击版本（使用 AND 和 OR），但并不转义字符串上下文。

SQL 盲注背后的概念是，即使不直接从数据库接收数据（以错误消息或泄漏的信息的形式），也可能从数据库中抽取数据（每次一个比特），或以恶意方式修改查询。其原理在于，应用程序的行为（返回与原始响应相同或不同的响应）可以提供有关所求值的（已修改）查询的单比特信息，也就是说，攻击者有可能设计出一个 SQL 布尔表达式，其求值（单比特）通过应用程序行为（与原始行为相同/不同）来造成破坏。

受影响产品

该问题可能会影响各种类型的产品。

引用和相关链接

• “Web Application Disassembly with ODBC Error Messages”（作者：David Litchfield）
• “Using Binary Search with SQL Injection”（作者：Sverre H. Huseby）
• Blind SQL Injection Training Module

 

SQL 盲注

可能会查看、修改或删除数据库条目和表

 

可能原因

未对用户输入正确执行危险字符清理

技术描述

该软件使用受外部影响的输入来构造 SQL 命令的全部或一部分，但是它未能对可能在 SQL 命令发送到数据库时修改该命令的元素进行无害化处理。如果在用户可控制的输入中没有对 SQL 语法充分地除去或引用，那么生成的 SQL 查询可能会导致将这些输入解释为 SQL 而不是普通用户数据。这可用于修改查询逻辑以绕过安全性检查，或者插入其他用于修改后端数据库的语句，可能包括执行系统命令。

例如，假设有一个带有登录表单的 HTML 页面，该页面最终使用用户输入对数据库运行以下 SQL 查询：

  SELECT * FROM accounts WHERE username='$user' AND password='$pass'

两个变量（$user 和 $pass）包含了用户在登录表单中输入的用户凭证。如果用户输入“jsmith”作为用户名，并输入“Demo1234”作为密码，那么 SQL 查询将如下所示：

  SELECT * FROM accounts WHERE username='jsmith' AND password='Demo1234'

但如果用户输入“'”（单撇号）作为用户名，输入“'”（单撇号）作为密码，那么 SQL 查询将如下所示：

  SELECT * FROM accounts WHERE username=''' AND password='''

当然，这是格式错误的 SQL 查询，并将调用错误消息，而该错误消息可能会在 HTTP 响应中返回。通过此类错误，攻击者会知道 SQL 注入已成功，这样攻击者就会尝试进一步的攻击媒介。SQL 盲注类似于 SQL 注入。不同之处在于，要利用该攻击，攻击者无需寻找响应中的 SQL 错误。因此，AppScan 用于识别该攻击的方法也不同。AppScan 会查找易受 SQL 注入（通过多个请求来操纵应用程序的逻辑，而不是尝试调用 SQL 错误）影响的脚本。

该技巧需要发送特定请求，其中易受攻击的参数（嵌入在 SQL 查询中的参数）进行了相应修改，以便响应中会指示是否在 SQL 查询上下文中使用数据。该修改涉及将 AND 布尔表达式与原始字符串一起使用，使其一时求值为 True，一时求值为 False。在一种情况下，净结果应该与原始结果相同（登录成功），而在另一种情况下，结果应该完全不同（登录失败）。在某些少见的情况下，求值为 True 的 OR 表达式也可能很有用。如果原始数据是数字，可以使用更简单的花招。假设原始数据为 123。此数据可以在一个请求中替换为 0+123，而在另一个请求中替换为 456+123。第一个请求的结果应该与原始结果相同，第二个请求的结果应该不同（因为得出的数字是 579）。在某些情况中，我们仍需要上面所说明的攻击版本（使用 AND 和 OR），但并不转义字符串上下文。

SQL 盲注背后的概念是，即使不直接从数据库接收数据（以错误消息或泄漏的信息的形式），也可能从数据库中抽取数据（每次一个比特），或以恶意方式修改查询。其原理在于，应用程序的行为（返回与原始响应相同或不同的响应）可以提供有关所求值的（已修改）查询的单比特信息，也就是说，攻击者有可能设计出一个 SQL 布尔表达式，其求值（单比特）通过应用程序行为（与原始行为相同/不同）来造成破坏。

受影响产品

该问题可能会影响各种类型的产品。

引用和相关链接

• “Web Application Disassembly with ODBC Error Messages”（作者：David Litchfield）
• “Using Binary Search with SQL Injection”（作者：Sverre H. Huseby）
• Blind SQL Injection Training Module

 

SQL 注入

可能会查看、修改或删除数据库条目和表

 

可能原因

未对用户输入正确执行危险字符清理

技术描述

该软件使用受外部影响的输入来构造 SQL 命令的全部或一部分，但是它对可能在所需 SQL 命令发送到数据库时修改该命令的特殊元素未正确进行无害化处理。如果在用户可控制的输入中没有对 SQL 语法充分地除去或引用，那么生成的 SQL 查询可能会导致将这些输入解释为 SQL 而不是普通用户数据。这可用于修改查询逻辑以绕过安全性检查，或者插入其他用于修改后端数据库的语句，并可能包括执行系统命令。

例如，假设有一个带有登录表单的 HTML 页面，该页面最终使用用户输入对数据库运行以下 SQL 查询：

  SELECT * FROM accounts WHERE username='$user' AND password='$pass'

两个变量（$user 和 $pass）包含了用户在登录表单中输入的用户凭证。因此，如果用户输入“jsmith”作为用户名，并输入“Demo1234”作为密码，那么 SQL 查询将如下所示：

  SELECT * FROM accounts WHERE username='jsmith' AND password='Demo1234'

但如果用户输入“'”（单撇号）作为用户名，输入“'”（单撇号）作为密码，那么 SQL 查询将如下所示：

  SELECT * FROM accounts WHERE username=''' AND password='''

当然，这是格式错误的 SQL 查询，并将调用错误消息，而该错误消息可能会在 HTTP 响应中返回。通过此类错误，攻击者会知道 SQL 注入已成功，这样攻击者就会尝试进一步的攻击媒介。

利用的样本：

以下 C# 代码会动态构造并执行 SQL 查询来搜索与指定名称匹配的项。该查询将所显示的项限制为其所有者与当前已认证用户的用户名相匹配的项。

  ...
  string userName = ctx.getAuthenticatedUserName();
  string query = "SELECT * FROM items WHERE owner = "'" 
  				+ userName + "' AND itemname = '"  
  				+ ItemName.Text + "'";
  sda = new SqlDataAdapter(query, conn);
  DataTable dt = new DataTable();
  sda.Fill(dt);
  ...

此代码打算执行的查询如下所示：

  SELECT * FROM items WHERE owner =  AND itemname = ;

但是，由于该查询是通过并置常量基本查询字符串和用户输入字符串来动态构造的，因此仅当 itemName 不包含单引号字符时，该查询才会正确运行。如果用户名为 wiley 的攻击者针对 itemName 输入字符串“name' OR 'a'='a”，那么查询将变为以下内容：

  SELECT * FROM items WHERE owner = 'wiley' AND itemname = 'name' OR 'a'='a';

添加 OR 'a'='a' 条件导致 where 子句始终求值为 true，因此该查询在逻辑上将变为等价于以下更简单的查询：

  SELECT * FROM items;

受影响产品

该问题可能会影响各种类型的产品。

引用和相关链接

• “Web Application Disassembly with ODBC Error Messages”（作者：David Litchfield）
• SQL Injection Training Module

 

已解密的登录请求

可能会窃取诸如用户名和密码等未经加密即发送了的用户登录信息

 

可能原因

诸如用户名、密码和信用卡号之类的敏感输入字段未经加密即进行了传递

技术描述

在应用程序测试过程中，检测到将未加密的登录请求发送到服务器。由于登录过程中所使用的部分输入字段（例如：用户名、密码、电子邮件地址、社会安全号等）是个人敏感信息，因此建议通过加密连接（例如 SSL）将其发送到服务器。

任何以明文传给服务器的信息都可能被窃，稍后可用来电子欺骗身份或伪装用户。

此外，若干隐私权法规指出，用户凭证之类的敏感信息一律以加密方式传给 Web 站点。

受影响产品

该问题可能会影响各种类型的产品

引用和相关链接

• 金融隐私权：The Gramm-Leach Bliley Act
• Health Insurance Portability and Accountability Act (HIPAA)
• Sarbanes-Oxley Act
• California SB1386

 

 

发现数据库错误模式

可能会查看、修改或删除数据库条目和表

 

可能原因

未对用户输入正确执行危险字符清理

技术描述

AppScan 在测试响应中发现数据库错误，该错误可能已被“SQL 注入”以外的攻击所触发。

虽然不确定，但这个错误可能表示应用程序有“SQL 注入”漏洞。

若是如此，请仔细阅读下列“SQL 注入”咨询。该软件使用受外部影响的输入构造整个 SQL 命令或 SQL 命令的一部分，但是会错误的无害化某些特殊元素，这些元素可在所需 SQL命令发送到数据库时对其进行修改。如果在用户可控制的输入中没有充分除去或引用 SQL 语法，那么生成的 SQL 查询可能会导致将这些输入解释为 SQL 而不是普通用户数据。这可用于修改查询逻辑以绕过安全性检查，或者插入其他用于修改后端数据库的语句，也可能包括执行系统命令。

例如，假设有一个带有登录表单的 HTML 页面，该页面最终使用用户输入对数据库运行以下 SQL 查询：

  SELECT * FROM accounts WHERE username='$user' AND password='$pass'

这两个变量（$user 和 $pass）包含了用户在登录表单中输入的用户凭证。因此，如果用户输入“jsmith”作为用户名，输入“Demo1234”作为密码，那么 SQL 查询将如下所示：

  SELECT * FROM accounts WHERE username='jsmith' AND password='Demo1234'

但如果用户输入“'”（单引号）作为用户名，输入“'”（单引号）作为密码，那么 SQL 查询将如下所示：

  SELECT * FROM accounts WHERE username=''' AND password='''

当然，这是格式错误的 SQL 查询，并将调用错误消息，而 HTTP 响应中可能会返回此错误消息。通过此类错误，攻击者会知道 SQL 注入已成功，这样攻击者就会尝试进一步的攻击媒介。

利用的样本：

以下 C# 代码会动态构造并执行 SQL 查询来搜索与指定名称匹配的项。该查询将所显示的项限制为其所有者与当前已认证用户的用户名相匹配的项。

  ...
  string userName = ctx.getAuthenticatedUserName();
  string query = "SELECT * FROM items WHERE owner = "'" 
  				+ userName + "' AND itemname = '"  
  				+ ItemName.Text + "'";
  sda = new SqlDataAdapter(query, conn);
  DataTable dt = new DataTable();
  sda.Fill(dt);
  ...

此代码打算执行的查询如下所示：

  SELECT * FROM items WHERE owner =  AND itemname = ;

但是，由于该查询是通过并置常量基本查询字符串和用户输入字符串来动态构造的，因此仅当 itemName 不包含单引号字符时，该查询才会正确运行。如果用户名为 wiley 的攻击者针对 itemName 输入字符串“name' OR 'a'='a”，那么查询将变为以下内容：

  SELECT * FROM items WHERE owner = 'wiley' AND itemname = 'name' OR 'a'='a';

添加 OR 'a'='a' 条件导致 where 子句始终求值为 true，因此该查询在逻辑上将变为等价于以下更简单的查询：

  SELECT * FROM items;

受影响产品

该问题可能会影响各种类型的产品。

引用和相关链接

• “Web Application Disassembly with ODBC Error Messages”（作者：David Litchfield）
• SQL Injection Training Module

 

自动填写未对密码字段禁用的 HTML 属性

可能会绕开 Web 应用程序的认证机制

 

可能原因

Web 应用程序编程或配置不安全

技术描述

“autocomplete”属性已在 HTML5 标准中进行规范。W3C 的站点声明该属性有两种状态：“on”和“off”，完全忽略时等同于设置为“on”。

该页面易受攻击，因为“input”元素的“password”字段中的“autocomplete”属性没有设置为“off”。

这可能会使未授权用户（具有授权客户机的本地访问权）能够自动填写用户名和密码字段，并因此登录站点。

受影响产品

不适用

引用和相关链接

不适用

 

HTML 注释敏感信息泄露

可能会收集有关 Web 应用程序的敏感信息，如用户名、密码、机器名和/或敏感文件位置

 

可能原因

程序员在 Web 页面上留下调试信息

技术描述

很多 Web 应用程序程序员使用 HTML 注释，以在需要时帮助调试应用程序。尽管添加常规注释有助于调试应用程序，但一些程序员往往会遗留重要数据（例如：与 Web 应用程序相关的文件名、旧的链接或原非供用户浏览的链接、旧的代码片段等）。

受影响产品

该问题可能会影响各种类型的产品。

引用和相关链接

• WASC 威胁分类：信息泄露
• CWE-615：通过注释泄露信息

 

发现电子邮件地址模式

可能会收集有关 Web 应用程序的敏感信息，如用户名、密码、机器名和/或敏感文件位置

 

可能原因

Web 应用程序编程或配置不安全

技术描述

Spambot 搜寻因特网站点，开始查找电子邮件地址来构建发送自发电子邮件（垃圾邮件）的邮件列表。

AppScan 检测到含有一或多个电子邮件地址的响应，可供利用以发送垃圾邮件。

而且，找到的电子邮件地址也可能是专用电子邮件地址，对于一般大众应是不可访问的。

受影响产品

该问题可能会影响各种类型的产品。

引用和相关链接

• Spambot 的定义（维基百科）
• CWE-359：隐私违例

 

发现可能的服务器路径泄露模式

可能会检索 Web 服务器安装的绝对路径，这可能会帮助攻击者开展进一步攻击和获取有关 Web 应用程序文件系统结构的信息

 

可能原因

未安装第三方产品的最新补丁或最新修订程序

技术描述

AppScan 检测到含有文件绝对路径（例如：Windows 的 c:\dir\file，Unix 的 /dir/file）的响应。

攻击者也许能够利用这项信息，从而访问到关于服务器机器目录结构的敏感信息，因而能够进一步攻击站点。

受影响产品

该问题可能会影响各种类型的产品。

引用和相关链接

CWE-200：信息泄露（信息披露）

 

 

客户端（JavaScript）Cookie 引用

此攻击的最坏情形取决于在客户端所创建的 cookie 的上下文和角色

 

可能原因

Cookie 是在客户端创建的

技术描述

cookie 是一则信息，通常由 Web 服务器创建并存储在 Web 浏览器中。

web 应用程序主要（但不只是）使用 cookie 包含的信息来识别用户并维护用户的状态。

AppScan 检测到客户端上的 JavaScript 代码用于操控（创建或修改）站点的 cookie。

攻击者有可能查看此代码、了解其逻辑并根据所了解的知识将其用于组成自己的 cookie，或修改现有 cookie。

攻击者可能导致的损坏取决于应用程序使用其 cookie 的方式或应用程序存储在这些 cookie 中的信息内容。

此外，cookie 操控还可能导致会话劫持或特权升级。

由 cookie 毒害导致的其他漏洞包含 SQL 注入和跨站点脚本编制。

受影响产品

该问题可能会影响各种类型的产品。

引用和相关链接

WASC 威胁分类：信息泄露

 

应用程序错误

可能会收集敏感的调试信息

 

可能原因

• 未对入局参数值执行适当的边界检查
• 未执行验证以确保用户输入与预期的数据类型匹配

技术描述

如果攻击者通过伪造包含非应用程序预期的参数或参数值的请求，来探测应用程序（如以下示例所示），那么应用程序可能会进入易受攻击的未定义状态。 攻击者可以从应用程序对该请求的响应中获取有用的信息，且可利用该信息，以找出应用程序的弱点。

例如，如果参数字段是单引号括起来的字符串（如在 ASP 脚本或 SQL 查询中），那么注入的单引号将会提前终止字符串流，从而更改脚本的正常流程/语法。

错误消息中泄露重要信息的另一个原因，是脚本编制引擎、Web 服务器或数据库配置错误。

以下是一些不同的变体：

[1] 除去参数

[2] 除去参数值

[3] 将参数值设置为空值

[4] 将参数值设置为数字溢出（+/- 99999999）

[5] 将参数值设置为危险字符，如 ' " \' \" ) ;

[6] 将某字符串附加到数字参数值

[7] 在参数名称后追加“.”（点）或“[]”（尖括号）

受影响产品

该问题可能会影响各种类型的产品。

引用和相关链接

• 使用单引号入侵站点的示例，可参阅“How I hacked PacketStorm (by Rain Forest Puppy), RFP's site”
• “Web Application Disassembly with ODBC Error Messages”（作者：David Litchfield）
• CERT 咨询（CA-1997-25）：清理 CGI 脚本中用户提供的数据

 

 

第三天 (5.11)

去西青参加大会，听取最新报告

 

新能源 车内空气 车用材料。。。

第四天 (5.12)

看牛客网视频 SQL注入相关

扫描靶机 并检查SQL注入相关问题