AppSensor –入侵检测

想象一下，您已经创建了一个不错的Web应用程序，并将其确保达到最佳状态。 用户来了，使用了它，一切正常，直到有人偶然发现并使用了您的应用程序中的漏洞。 当然，您分析了日志，发现坏人一直在寻找该漏洞数周，直到找到一个为止。

AppSensor入侵检测框架的创建者认为，上述情况不应该发生。 该应用程序不应该只躺在那里，而应该通过SQL注入，XSS攻击和其他任何方式击败自己。 应该采取积极措施保护自己。 由于一般的攻击者必须进行几次尝试才能找到应用程序中的漏洞，因此应该有可能检测到黑客攻击。

应用程序内入侵检测框架的思想似乎很原始。 尽管入侵检测框架在网络安全领域很常见，但我们发现AppSensor别无选择。 如果您知道一个，请告诉我们。

AppSensor项目

AppSensor是开放式Web应用程序安全性项目 （OWASP）项目的一部分。 它最初是一个概念框架，后来演变成一个真正的图书馆。 该项目目前处于测试阶段。

AppSensor位于两个位置：

• OWASP（开放式Web应用程序安全性项目）Wiki上的页面 ，
• 谷歌代码页 。

创作者撰写了简短易读的书，其中包含项目概述，建议和最佳实践。 即使您决定实施自己的解决方案，这本书也值得一读。 如果您决定使用AppSensor，则可以在Google代码上找到开发人员入门指南。

总览

高层次的设计既好又简单。 AppSensor具有检测点，响应动作和入侵检测器。 检测点能够检测正在进行或可能的攻击。 它们会在应用程序中传播，并在满足入侵条件时引发应用程序传感器异常。

例如，HTTP方法GET请求仅在页面上仅期望POST请求的页面时，“ GET期望POST”检测点就会触发警告。 如果请求包含常见的XSS攻击模式，则“跨站点脚本尝试”检测点将引发异常。

入侵检测器会分析所有引发的异常。 如果检测到正在进行的攻击，它将决定需要采取哪种响应措施。 从提高日志级别到关闭整个应用程序，响应措施都可以做。 选择哪种操作取决于可疑活动和应用程序的性质。 在交易应用程序将立即禁用用户帐户的情况下，讨论论坛只会提高日志级别并警告用户停止活动。

AppSensor是企业安全性API（ESAPI）项目的一部分。 开箱即用的版本仅支持受ESAPI保护的项目。 但是，我们的示例应用程序是使用Shiro框架保护的。 另一个博客文章中介绍了这两个框架之间的集成。

不要伤害

虽然入侵检测系统的全部重点是检测并阻止正在进行的黑客攻击，但同样重要的是不要伤害无辜的用户。 AppSensor本书建议将检测点分为两类：

• 攻击事件
• 可疑事件。

如果一个隐藏的表单变量突然包含“'OR 1 = 1””，那么毫无疑问有人在入侵该应用程序。 该事件被视为攻击事件，系统可能会对用户采取强硬措施（注销，禁用帐户）。

另一方面，请求参数中的意外“;”仅被视为可疑。 也许是错字。 也许是恶意的黑客试图保持低调。 众所周知，只有事件在多个字段上发生多次时，我们才能得出系统受到攻击的结论。 在这种情况下，系统应记录该事件并提高当前用户的日志级别。 只有在重复发生事件之后，才会采取更强有力的行动。

当然，应用程序上下文也很重要。 提交给交易应用程序“姓氏”字段的意外<img> html标签必须认真对待。 可以轻视讨论论坛中相同的禁止<img>标签。 用户可能正在尝试向其用户名添加动画或其他内容。 这很烦人，但几乎不是攻击。

应用范例

我们已经在作为Apache Shiro系列的一部分创建的SimpleShiroSecuredApplication上测试AppSensor。 您可以从Github上的intrusion_detection分支下载示例。 使用测试类RunTestWait测试用例运行Web服务器，并将应用程序部署在https：// localhost：8443 / simpleshirosecuredapplication / URL上。

该应用程序有七个用户：管理员，Friendlyrepairman，unfriendlyrepairman，数学家，物理学家，产品销售和服务销售。 它们都共享相同的密码：“ heslo”。

添加AppSensor

首先，我们必须将AppSensor依赖项添加到应用程序中，并在ESAPI配置中启用该框架作为入侵检测提供程序。 即使我们不在项目中使用ESAPI，也必须这样做。

将AppSensor依赖项添加到pom.xml：

org.owasp.appsensor
  
  
  
   AppSensor
  
  
  
   0.1.3.2
  
  
  
   jar
  
  
  
   compile

在src / main / resources文件夹中创建“ .esapi”文件夹。 给Eclipse用户的提示：eclipse软件包浏览器不显示名称以开头的文件和文件夹。 （期）。 要显示它们，请转到包浏览器视图，然后按视图右上角的小向下箭头。 单击过滤器，然后取消选中“。*资源”条目。

解压AppSensor jar文件并复制三个配置文件

• .esapi / appsensor.properties – AppSensor配置，
• .esapi / validation.properties – ESAPI输入验证配置，
• .esapi / ESAPI.properties – ESAPI配置

放入resource / .esapi文件夹。 或者，您可以从Google代码存储库下载它们。 在更改ESAPI.IntrusionDetector进入ESAPI.properties文件中使用AppSensor入侵检测：

ESAPI.IntrusionDetector = org.owasp.appsensor.intrusiondetection.AppSensorIntrusionDetector

积分

仅当某些用户动作被同一用户重复太多次时，它们才被视为威胁。 此外，入侵检测器可以确定需要“注销用户”或“禁用帐户”响应动作。 所有这些都需要访问基础应用程序数据和API。

默认的AppSensor配置假定应用程序支持ESAPI接口。 但是，SimpleShiroSecuredApplication由具有不同功能集的Shiro框架保护。 由于两个框架之间的集成更多是关于Shiro而不是AppSensor，因此我们将其移至单独的post 。

检测点

OWASP页面包含大量建议的检测点列表。 它包含几乎所有可能的内容。 检测点分为几类：

• 请求和会话–使用URL，请求，Cookie等进行操作
• 输入–用户输入包含常见的XSS攻击，不寻常的字符，输入的文本长于输入字段的大小，…
• 亲爱的陷阱–否则将修改具有诱人名称is_admin的未使用的隐藏字段或请求变量，请求仅在html注释中可用的url，…
• 用户或系统趋势–网站上的注销次数过多，用户点击的速度快于人工操作的速度，用户过于频繁地更改其名字字段，…
• …

为了找出可能由无辜活动触发的检测点，我们付出了很多努力。 这些检测点大多数尚未实现。 AttackDetectorUtils类包含大多数已实现的检测点：

• 意外的请求方法，
• xss攻击，
• sql注入
• 请求参数中的空字节，
• Cookies存在，
• 回车或换行。

另外，有两个servlet过滤器可用：

• 验证用户代理是否在会话中更改了（ UserAgentChangeDetectionFilter ），
• 验证IP地址是否在会话中更改（ IpAddressChangeDetectionFilter ）。

当心：请小心，在使用前需要重新配置xss和sql注入检测点（ 稍后将对此进行详细介绍）。

添加检测点

每个检测点都有唯一的代码。 如果应用程序检测到入侵或可疑事件，则可以使用代码引发AppSensorException：

if (intrusionDetected()) {
  new AppSensorException("CODE", "Message to user.", "Log message.");
};

注意：没有“ throw”子句。 异常构造函数会自动触发它。

或者，可以在AttackDetectorUtils类中使用准备好的检测点：

AttackDetectorUtils.verifyXSSAttack(inputValue)

或者您可以在web.xml中配置servlet过滤器：

IpChangedDetectionPoint
  
  
  
    org.owasp.appsensor.filters.IpAddressChangeDetectionFilter 
  
 
 

 
 
  
  
   IpChangedDetectionPoint
  
  
  
   /*

每个检测点都有入侵阈值和相关的响应动作。 阈值是在采取相关操作之前的时间段内所需的许多事件。

例如，如果入侵异常CODE在十分钟之内被引发四次，则它被视为攻击。 如果第一次达到阈值，则仅记录该事件。 用户第二次违规后退出。 第三次进攻（例如，在十分钟之内引发十二次异常）将完全禁用用户帐户：

# number of intrusions in a specified segment of time that constitutes the upper threshold - once crossed, it's considered an "attack"
IntrusionDetector.CODE.count=4
# time period (in seconds)
IntrusionDetector.CODE.interval=600
# list of actions you want executed in the specified order
IntrusionDetector.CODE.actions=log, logout, disable

XSS攻击和SQL注入检测

我们从检测点开始，检测点检测Web应用程序上的两种流行攻击：SQL注入和XSS攻击。 每当应用程序从请求参数读取值时，该值就会传递到检测点：

/**
 * Reads sanitized request parameter value from request.
 */
protected String getField(HttpServletRequest request, String parameter) {
  String dirtyValue = request.getParameter(parameter);
  
  // detection point: XSS, SQL injection
  AttackDetectorUtils.verifySQLInjectionAttack(dirtyValue);
  AttackDetectorUtils.verifyXSSAttack(dirtyValue);
  
  return sanitizer.sanitize(dirtyValue);
}

根据AppSensor的书，只要攻击者尝试进行SQL注入或XSS攻击，这些检测点就会检测到入侵。 如果是这种情况，系统应该对用户采取强有力的行动。 我们在appsensor.properties文件中配置了它：

# XSS attack -- be careful about these settings
# clear attack event, taking action immediately 
IntrusionDetector.IE1.count=1
# clear log after 20 minutes
IntrusionDetector.IE1.interval=1200
# first offense log user out, second disable account  
IntrusionDetector.IE1.actions=logout, disable

# SQL injection -- be careful about these settings
# clear attack event, taking action immediately 
IntrusionDetector.CIE1.count=1
# clear log after 20 minutes
IntrusionDetector.CIE1.interval=1200
# first offense log user out, second disable account  
IntrusionDetector.CIE1.actions=logout, disable

但是，我们建议对此非常小心。 打开SimpleShiroSecuredApplication的“个人帐户页面”，然后将以下字符串之一放入任何字段中：

The dog should fetch the stick as soon as possible.

please delete all unused configuration files

Any text with ; in it.

SQL注入检测点在它们中的任何一个之后都会触发异常。

该问题是由第一条消息中的单词fetch，第二条消息中的单词delete和符号';'引起的。 在最后一条消息中。 它们在标准英语文本中很常见，但是所有这些都会引发SQL注入异常。

XSS攻击检测点也可能导致误报（但是可能性较小）：

Hi, 
thank you for installation scripts and requirements document.cookies has been delicious, please bring them again :)).
See you soon,
Andy

在appsensor.properties文件中配置了默认的攻击模式。 使用标准的Java正则表达式：

# This collection of strings is the XSS attack pattern list
xss.attack.patterns=\"><script>,script.*document\\.cookie,<script>,<IMG.*SRC.*=.*script,<iframe>.*</iframe>

# This collection of strings is the SQL Injection attack pattern list
sql.injection.attack.patterns=\\-\\-,\\;,\\/\\*,\\*\\/,\\@\\@,\\@,nchar
,varchar,nvarchar,
alter,cursor,delete,drop,exec,fetch,insert,kill,sysobjects,syscolumns

我们强烈建议将这些列表更改为不太严格的内容。

响应动作

该项目还包含可能的响应措施列表。 建议的操作分为以下几类：

• 静默–记录更改，管理员通知，…
• 被动–显示警告，降低用户的应用程序速度，…
• 有效–注销，禁用模块，需要其他验证（验证码），…
• 侵扰性-注意保持合法性

AppSensor仅实施七个响应动作。 在我们的应用程序中有五个可用：

• 记录事件
• 注销用户，
• 禁用用户帐户，
• 发送短信给管理员，
• 电子邮件管理员。
• 禁用组件，
• 为用户禁用组件。

这两个禁用组件响应操作都将锁定对上次调用URL的访问。 它们都需要其他配置。

请记住，响应动作可能会大大改变代码行为。 例如，它可能导致看似随机的意外用户注销，这可能导致意外的空指针异常或其他类似问题。 您的设计必须足够健壮，才能正确处理此类情况。

禁用组件

如果您想使用“用户禁用组件”响应行动“禁用成分”或者，你必须创建页面将显示，而不是阻止页面：

<title>Access Denied</title>
</head>
<body>
Sorry, you do not have access rights to that area.
</body>
</html>

只有以appsensor.properties中配置的后缀结尾的URL 才是可阻止的。 我们将仅使用jsp和html页面。 我们所有的servlet都有后缀servlet：

# This is the list of extensions to check for disabling, ie. jsp (for jsp's), do (for struts 1), UpdateProfile (for the UpdateProfile servlet) 
disable.component.extensionsToCheck=jsp,html,servlet,

无法配置“所有页面后缀无关紧要”。 您必须列出所有可能的后缀。 但是，您可以配置永远不会被阻止的异常。 由于不使用它，因此将保留默认配置：

# This is the list of exceptions to disabling components, 
ie this list should never be disabled
disable.component.exceptions=/AppSensorDemo/appsensor_locked.jsp,
/AppSensorDemo/login.jsp,/AppSensorDemo/updateProfile.jsp

在web.xml中启用禁用组件操作：

AppSensorBlockComponent
  
 
  
    org.owasp.appsensor.filters.AppSensorRequestBlockingFilter 
  
 
  
  
   
    redirectURL
   
   
    /simpleshirosecuredapplication/account/accessdenied.jsp 
   
  

 


 
 
  
   AppSensorBlockComponent
  
 
  
   /*

AppSensor将已阻止的请求重定向到redirectURL。

最后，在appsensor.properties文件的检测点配置中配置了禁用组件响应操作。 “为用户禁用组件”的配置如下所示：

# some integer - duration of time to disable
IntrusionDetector.ACTION_DOES_NOT_EXISTS.disableComponentForUser.duration=30
# some measure of time, currently supported are s,m,h,d (second, minute, hour, day)
IntrusionDetector.ACTION_DOES_NOT_EXISTS.disableComponentForUser.timeScale=m

“禁用组件”的配置类似。 默认持续时间为0，因此如果不配置该操作，则该操作不执行任何操作。 使用常数-1可以永久禁用组件。

自定义响应动作

如果计划在应用程序中使用AppSensor，则可能需要添加新的响应操作或修改默认响应操作。

默认响应动作由DefaultResponseAction类处理。 如果需要不同的响应动作集，则必须实现ResponseAction接口。 以下类添加了“警告用户”操作：

public class CustomResponseAction implements ResponseAction {
 
 private final ResponseAction delegee=DefaultResponseAction.getInstance();

  @Override
  public boolean handleResponse(..., AppSensorIntrusion currentIntrusion) {
  if ("warn".equals(action)) {
   Exception securityException = currentIntrusion.getSecurityException();
   String localizedMessage = securityException.getLocalizedMessage();
   
   ASUtilities asUtilities = APPSENSOR.asUtilities();
   HttpServletRequest request = asUtilities.getCurrentRequest();
   request.setAttribute("securityWarning", localizedMessage);
   
   return true;
  }
   
   return delegee.handleResponse(action, currentIntrusion);
  }

}

在appsensor.properties文件中启用新类：

# This is the class that handles the response actions
AppSensor.responseAction = org.meri.simpleshirosecuredapplication.intrusiondetection.responseaction.CustomResponseAction

注意：如果要扩展DefaultResponseAction，则必须重写静态方法getInstance（）。 否则，负责初始化的类将创建DefaultResponseAction的实例。

入侵商店

所有检测到的入侵都存储在入侵存储对象中。 默认入侵存储提供了非常简单的实现：它将所有入侵以静态形式存储在内存映射中。 它不适用于群集环境，并且系统重新启动后所有存储的数据都会丢失。

如果有特殊需要，可以用自己的解决方案代替。 实现IntrusionStore接口并在appsensor.properties文件中对其进行配置：

# This is the class that handles the intrusion store
AppSensor.intrusionStore = org.owasp.appsensor.intrusiondetection.reference.DefaultIntrusionStore

总体印象

AppSensor是个好主意，也是我所知道的唯一入侵检测框架。 该项目制作了易于阅读的免费电子书，值得花一些时间玩。 框架设计（例如划分到检测点，入侵检测器和响应动作）是切实可行的。

该项目仍处于测试阶段，有时会显示。 XSS攻击和SQL注入检测点的默认配置太严格，在撰写本文时，我们发现了一些小错误。 但是，项目提交者对提交的问题的响应始终很快。

缺少多个预期的小功能。 不可能说“所有URL都是可阻止的”。 用户必须手动将所有后缀添加到extensionsToCheck中。 由于在appsensor.properties文件的检测点块中配置了默认响应动作，因此我们也希望为自定义动作提供相同的配置支持。 或者，某些类（DefaultResponseAction）毫无理由是单例。

如果您决定在项目中使用入侵检测，则您的设计必须足够健壮，以处理所有这些随机注销和帐户禁用。

参考： AppSensor –我们的JCG合作伙伴 Maria Jurcovicova在This is Stuff博客上的入侵检测 。

翻译自: https://www.javacodegeeks.com/2012/05/appsensor-intrusion-detection.html