用日志与监控构建安全的应用程序
新客网 XKER.COM 2008-03-18 来源：赛迪网 收藏本文
如果是这样，则攻击者可以手动或者自动地对输入域进行Fuzzing攻击，而安全操作人员可能无法发现应用程序正受到威胁。分析上面的输出，如果不知道每个程序员使用的语法的话，一个分析工具怎样才能把上面的两个事件关联起来，预告可能的SQL注入攻击呢？
采用集中处理器解决问题
解决这些问题的一个方法是：根据应用程序逻辑设计一个集中的日志处理器。创建一个静态类，我们把它命名为“AppLog”以便讨论。AppLog实际上是当前应用程序与日志分析工具之间的适配器。AppLog至少提供四个公共的调用方法：
·AppLog.logDebugMessage(logMessage, logPriority, callingObject)
·AppLog.logSecurityMessage(logMessage, logPriority, callingObject)
·AppLog.logBusinessLogicError(logMessage, logPriority, callingObject)
·AppLog.logSystemMessage(logMessage, logPriority, callingObject)
这个方法强制编程人员选择一种日志类型，而不是简单地选择一个优先级，同时logPriority参数为他们保留了选择优先级的功能。CallingObject参数允许AppLog自动地扩展调用实例的类型。此外，AppLog可以在实际写入日志文件或者使用Log4J和Log4Net之前为某个特定的日志分析工具加入语法参数；可以为每个分析工具建立新的AppLog子类。除了AppLog和其子类的执行，程序员不必关心外部分析工具的具体语法。
但是仅仅这样并不能解决上述所有问题。两个开发人员仍然可以把不同的消息传递给logSecurityMessage()函数。为了解决此问题，程序员必须在AppLog加入针对每个安全事件的特殊处理函数，如logInvalidAccessAttempt(user_id, timestamp, callingObject)和logSQLInjectionAttempt(user_id, timestamp, maliciousChar, inputString, callingObject)。这些函数将构建不同的消息然后调用logSecurity函数。最终记录的事件可能是：
"code:312,app:MyApp,event:Invalid_auth_attempt,user:admin,time:3713252,
calling-obj:com.mycompany.package.MyClass"
这种语法对特定的日志分析工具来说是有意义的，如果分析工具发生了改变，那么我们只要简单地改变AppLog或者它的子类的函数，而不是整个应用程序的日志处理函数。由于开发人员不必去揣测用哪个英文短语来描述非法的访问尝试（例如，“Login failed”），不同模块的开发人员在记录非法访问尝试时会使用相同的语法。
让我们再回顾一下SQL注入的例子，集中处理函数两次调用logSQLInjectionAttempt函数，产生的日志文件可能是：
1st event:
"code:312,app:MyApp,event:sql_injection_attempt,user:myuser1,mal-char:"-",input-string:"
Some description' OR 1=1 --;
",time:371245,calling-
obj:com.mycompany.DAO.CustomerDAO"
2nd event:
"code:312,app:MyApp,event:sql_injection_attempt,user:myuser1,mal-char:"-",input-
string:"An order name' OR 1=1
--;",time:371253,calling-
obj:com.mycompany.DAO.OrderDAO"
管理员可以配置日志分析工具，使它们能解析出同一个用户在一个很短的时间内有两次或者更多次SQL注入尝试，这通过协调的日志格式很容易就能做到。当然，如果你的应用程序遭到这种常规方式的注入尝试，也许在两个SQL注入尝试之后就给安全操作人员发出警告，可能会使安全操作人员对分析感到厌烦。在这种情况下，管理员可以简单地配置工具，在足够的注入尝试次数（如100或者1000）之后再给安全操作人员发出警告。
记录日志是基础设施的责任？
一些人可能会认为，这个方法用来解决应用层日志的问题是错误的。他们主张，这些功能必须在基础设施的某个地方实现，例如，LDAP目录或者Web应用程序防火墙。但是，在基础设施层记录每一个安全日志是不可能的，通过程序开发人员处理安全问题有很大的益处。此外，如果没有应用程序逻辑，有一些安全事件根本无法检测到，例如，在注册页面有些用户输入了错误的验证码值。因此，开发人员应该与底层的基础设施一起共同识别与安全相关的事件。
低成本的投资
除了日志分析引擎的成本外，建立这样一个日志处理系统是一个相当实惠的实践。执行这个方法只要制定一套标准，然后建立一个简单的适配器依附于这个标准，并把这个标准告诉开发人员。即使在短期内可能不会使用日志分析工具，如果在应用程序设计时增加这项功能，那么在最终使用日志分析工具时将可以很方便地运用这项功能。还有，标准化工作使得日志易于读取和理解。大部分企业级开发人员承认在发现问题需要处理时，他们依靠应用程序的日志，但是对这些日志进行分类整理是一件非常困难、非常耗时的工作，因为这些日志数量很大而且语法非常随意。采用本文的方法，在人工分析日志时，只要生成像CSV一样的易于解析的日志格式，这样就可以用喜欢的电子表格程序来分析它们。
改写代码的成本
一些程序员和架构师指出，改写代码的成本和风险是很大的。如果本文的方法被正确地采用，标准化的日志将会产生最小限度的影响，风险也很低，因为只要改变非功能性代码的语法就可以了。
这就是说，对于几万行或者几十万行代码的应用程序，简单的改写代码工作将起到巨大的作用。在这种情况下，开始时对安全性敏感的领域（例如，认证、授权、Session管理、输入验证、配置、管理）执行新的标准；在日志格式发现变化时，保证新引入的代码与新的日志格式保持一致。
对应用程序安全提前做好处理，是一个很划算的IT管理方法，它将会建立安全的应用程序。
采用集中处理器解决问题
解决这些问题的一个方法是：根据应用程序逻辑设计一个集中的日志处理器。创建一个静态类，我们把它命名为“AppLog”以便讨论。AppLog实际上是当前应用程序与日志分析工具之间的适配器。AppLog至少提供四个公共的调用方法：
·AppLog.logDebugMessage(logMessage, logPriority, callingObject)
·AppLog.logSecurityMessage(logMessage, logPriority, callingObject)
·AppLog.logBusinessLogicError(logMessage, logPriority, callingObject)
·AppLog.logSystemMessage(logMessage, logPriority, callingObject)
这个方法强制编程人员选择一种日志类型，而不是简单地选择一个优先级，同时logPriority参数为他们保留了选择优先级的功能。CallingObject参数允许AppLog自动地扩展调用实例的类型。此外，AppLog可以在实际写入日志文件或者使用Log4J和Log4Net之前为某个特定的日志分析工具加入语法参数；可以为每个分析工具建立新的AppLog子类。除了AppLog和其子类的执行，程序员不必关心外部分析工具的具体语法。
但是仅仅这样并不能解决上述所有问题。两个开发人员仍然可以把不同的消息传递给logSecurityMessage()函数。为了解决此问题，程序员必须在AppLog加入针对每个安全事件的特殊处理函数，如logInvalidAccessAttempt(user_id, timestamp, callingObject)和logSQLInjectionAttempt(user_id, timestamp, maliciousChar, inputString, callingObject)。这些函数将构建不同的消息然后调用logSecurity函数。最终记录的事件可能是：
"code:312,app:MyApp,event:Invalid_auth_attempt,user:admin,time:3713252,
calling-obj:com.mycompany.package.MyClass"
这种语法对特定的日志分析工具来说是有意义的，如果分析工具发生了改变，那么我们只要简单地改变AppLog或者它的子类的函数，而不是整个应用程序的日志处理函数。由于开发人员不必去揣测用哪个英文短语来描述非法的访问尝试（例如，“Login failed”），不同模块的开发人员在记录非法访问尝试时会使用相同的语法。
让我们再回顾一下SQL注入的例子，集中处理函数两次调用logSQLInjectionAttempt函数，产生的日志文件可能是：
1st event:
"code:312,app:MyApp,event:sql_injection_attempt,user:myuser1,mal-char:"-",input-string:"
Some description' OR 1=1 --;
",time:371245,calling-
obj:com.mycompany.DAO.CustomerDAO"
2nd event:
"code:312,app:MyApp,event:sql_injection_attempt,user:myuser1,mal-char:"-",input-
string:"An order name' OR 1=1
--;",time:371253,calling-
obj:com.mycompany.DAO.OrderDAO"
管理员可以配置日志分析工具，使它们能解析出同一个用户在一个很短的时间内有两次或者更多次SQL注入尝试，这通过协调的日志格式很容易就能做到。当然，如果你的应用程序遭到这种常规方式的注入尝试，也许在两个SQL注入尝试之后就给安全操作人员发出警告，可能会使安全操作人员对分析感到厌烦。在这种情况下，管理员可以简单地配置工具，在足够的注入尝试次数（如100或者1000）之后再给安全操作人员发出警告。
记录日志是基础设施的责任？
一些人可能会认为，这个方法用来解决应用层日志的问题是错误的。他们主张，这些功能必须在基础设施的某个地方实现，例如，LDAP目录或者Web应用程序防火墙。但是，在基础设施层记录每一个安全日志是不可能的，通过程序开发人员处理安全问题有很大的益处。此外，如果没有应用程序逻辑，有一些安全事件根本无法检测到，例如，在注册页面有些用户输入了错误的验证码值。因此，开发人员应该与底层的基础设施一起共同识别与安全相关的事件。
低成本的投资
除了日志分析引擎的成本外，建立这样一个日志处理系统是一个相当实惠的实践。执行这个方法只要制定一套标准，然后建立一个简单的适配器依附于这个标准，并把这个标准告诉开发人员。即使在短期内可能不会使用日志分析工具，如果在应用程序设计时增加这项功能，那么在最终使用日志分析工具时将可以很方便地运用这项功能。还有，标准化工作使得日志易于读取和理解。大部分企业级开发人员承认在发现问题需要处理时，他们依靠应用程序的日志，但是对这些日志进行分类整理是一件非常困难、非常耗时的工作，因为这些日志数量很大而且语法非常随意。采用本文的方法，在人工分析日志时，只要生成像CSV一样的易于解析的日志格式，这样就可以用喜欢的电子表格程序来分析它们。
改写代码的成本
一些程序员和架构师指出，改写代码的成本和风险是很大的。如果本文的方法被正确地采用，标准化的日志将会产生最小限度的影响，风险也很低，因为只要改变非功能性代码的语法就可以了。
这就是说，对于几万行或者几十万行代码的应用程序，简单的改写代码工作将起到巨大的作用。在这种情况下，开始时对安全性敏感的领域（例如，认证、授权、Session管理、输入验证、配置、管理）执行新的标准；在日志格式发现变化时，保证新引入的代码与新的日志格式保持一致。
对应用程序安全提前做好处理，是一个很划算的IT管理方法，它将会建立安全的应用程序。
最新相关文章发表评论
评论内容：不能超过250字，需审核后才会公布，请自觉遵守互联网相关政策法规。
阅读排行
随机推荐
实用信息推荐