Build Secure applications with coordinated logs and monitoring

Based on the author's years of Security Analysis on millions of lines of code, this article draws a conclusion about the vulnerability in application-layer logs. This article discusses the security aspects of applications, logs are often ignored, and proves that applications can obtain many benefits through real-time security checks. This article proposes an operational implementation approach and provides related risk and cost analysis.

Application Security Driver

Developers and security personnel begin to pay attention to security programming practices. In fact, IT vendors are also taking advantage of this trend to ensure the security of applications and infrastructure for users. Unfortunately, however, many believe that access control and encryption cover almost all areas of application security.

In fact, some other fields are also included in application security. OWASP Guide is a good starting point for identifying these fields. Industry Development Teams have different understandings of OWASP-identified fields. For example, most developers have realized that they cannot develop their own encryption algorithms, but few are aware of the problems caused by the use of pseudo-Random number generators (such as java. util. Random) to generate Session IDs. Another special area ignored by many people is log and monitoring.

Detect attacks at the application layer

In a typical enterprise environment, few applications have built-in functions for detecting and notifying potential malicious behaviors. On the contrary, these software relies on basic devices, such as firewalls, to execute this function. However, there may inevitably be some attacks, which may bypass the protection mechanism of the device: for example, DoS attacks from internal networks, or attackers can bypass the client authentication and be attacked by the enterprise network as legal traffic. Of course, blocking part of these attacks is the task of Network-layer intrusion detection systems and intrusion prevention systems. However, with the emergence of website services and the development of cooperative access between internal networks and network boundaries, individual IDS/IPS systems may not be able to detect these attacks.

Of course, setting an intrusion detection engine for each application is impractical. In fact, this method of configuring the intrusion detection engine conflicts with the application security principle: "You need to program securely, rather than writing another security tool ". A more feasible method is to use a log file analysis engine to read log files in real time and use intelligent rules to find attack modes. These tools already exist, such as Sawmill and Network Intelligence. They are not designed for log file analysis of a specific application. By configuring these tools, they can meet the needs of multiple applications. This article does not discuss these tools in depth; it focuses on how to make applications meet the requirements of these tools. Most applications lack a standard format and coordination method to record logs, so that the analysis engine can extract useful information from log files.

Example 1: authentication logs in applications

Many applications, including those that comply with the CMM Level 5 organization, are using uncoordinated log modes. The following example shows how a Java program uses Log4J to record illegal request verification. Note that in the C #. Net field, this example must use Log4net instead of Log4J. This article assumes that some log tools are being used, and how to configure and deploy such tools is not discussed here.

If (! Request. password. equals (result. password ))
{// User supplied wrong p/w
Log. debug ("Invalid access attempt for" + request. usernane +"
With password "+ request. password );
...

The same application may use the following interface in the user authentication module:

If (myRequest. getPassword ()! = Data. getPassword ()){
Log.info ("Login failed ");
...

In addition to the obvious security vulnerability that does not encrypt passwords, the preceding encoding method has some other problems:

The two examples use different log levels ("debug" and "info") to record failed authentication attempts. This means that each programmer must independently determine the sensitivity of a log event. When a programmer thinks this is a debugging event, another programmer may think it is a little important and determines it as the second-level ("log") log, this means that these events will be written to different log files. The Analysis of failed authentication attempts will become complicated or even impossible.

The two examples use different syntaxes. This will once again be attributed to the individual habits of every programmer when logging. Many programmers regard low-level logs as an extension of debugging information and do not follow relevant standards. The above example only shows the differences between the two programmers. in actual application development, there may be dozens, hundreds, or even thousands of programmers who use their respective syntaxes, which may make analyzing this information a terrible thing. In addition, this does not guarantee that, if the Log changes, these analyses will still make sense in the new software version.

Log4J, Log4Net, and most other similar tools will accurately record the parameters passed by the caller as logs. If an application uses a log analysis tool, it expects a special syntax (for example, "AppName, LogMessage, TimeStamp, Date "), the developer will be forced to use this syntax to record log events. If the syntax of a new analysis tool or old tool has changed, the developer must update each related call function in the application.

These events are security-related, but cannot be differentiated. They will be associated with debugging information (for example, uninitialized variables), business logic errors (for example, there is a table field not filled in) and system errors (for example, the database server crashes) are written to the log file together.

Example 2: SQL Injection logs of applications

Let's look at another example: An input verification program finds that a string may be used for SQL injection attacks. Note: In this example, the "Blacklist" or "known dangerous characters" test method is used. Although this method is not a perfect input verification method, it is often used:

If (! Request. desc. indexOf (';')! = 0)

{// Possible SQL Injection character

Log. fine ("Possible SQL injection character; in request. desc

Value of "+ request. desc );

Similarly, the severity of an attack is determined by the programmer. There is no standard information for the automatic analysis engine to determine whether an input verification attack exists. A single Malicious character may be unintentional, but if there are multiple such events, you may need to pay attention to them. Since there is no way to associate these events in real time, the operator cannot properly respond to the event (for example, locking a malicious IP address ).

In this example, logs must be recorded in a more coordinated manner. Imagine if an attacker attempts to execute SQL injection attacks from different input domains, these domains are often mapped to different instances (for example, CustomerDAO) at the Data Access Object Layer. java, OrderDAO. java and so on ). If these instances are developed by different programmers, the log recording syntax may be different. Below is the possible output of conventional log files:

1st event:
Warning: SQL Injection detected: "Some description OR 1 = 1 --;"
...
2nd event:
Possibility of malicious input, found character "-" in input field.

In this case, attackers can manually or automatically perform Fuzzing attacks on the input domain, while security operators may not find that the application is under threat. Analysis of the above output, if you do not know the syntax used by each programmer, how can an analysis tool associate the above two events to predict possible SQL injection attacks?

Solve problems with a centralized Processor

One way to solve these problems is to design a centralized log processor based on the application logic. Create a static class and name it "AppLog" for discussion. AppLog is actually an adapter between the current application and the log analysis tool. AppLog provides at least four common call methods:

· AppLog. logDebugMessage (logMessage, logPriority, callingObject)

· AppLog. logSecurityMessage (logMessage, logPriority, callingObject)

· AppLog. logBusinessLogicError (logMessage, logPriority, callingObject)

· AppLog. logSystemMessage (logMessage, logPriority, callingObject)

This method forces programmers to select a log type, rather than simply selecting a priority, while the logPriority parameter retains the priority selection function for them. The CallingObject parameter allows AppLog to automatically extend the type of the called instance. In addition, AppLog can add syntax parameters for a specific log analysis tool before actually writing a log file or before using Log4J and Log4Net. It can create a new AppLog subclass for each analysis tool. In addition to AppLog and its sub-classes, programmers do not have to worry about the specific syntax of external analysis tools.

However, this alone cannot solve all the above problems. Two developers can still pass different messages to the logSecurityMessage () function. To solve this problem, the programmer must add special processing functions for each security event in AppLog, such as logInvalidAccessAttempt (user_id, timestamp, callingObject) and logSQLInjectionAttempt (user_id, timestamp, maliciousChar, inputString, callingObject ). These functions construct different messages and then call the logSecurity function. The events recorded may be:

"Code: 312, app: MyApp, event: Invalid_auth_attempt, user: admin, time: 3713252,
Calling-obj: com. mycompany. package. MyClass"

This syntax makes sense for a specific log analysis tool. If the analysis tool changes, we only need to simply change the AppLog or its subclass function, instead of the log processing function of the entire application. Because developers do not have to speculate which English phrase to use to describe illegal access attempts (for example, "Login failed "), developers of different modules use the same syntax when recording illegal access attempts.

Let's review the SQL Injection example. The concentrated processing function calls the logSQLInjectionAttempt function twice. The generated log files may be:

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: myapps, event: SQL _injection_attempt, user: myuser1, mal-char:"-", input-
String: "An order name OR 1 = 1

--; ", Time: 371253, calling-
Obj: com. mycompany. DAO. OrderDAO"

The administrator can configure log analysis tools so that they can parse the two or more SQL Injection attempts of the same user in a short period of time, this can be easily achieved through the coordinated log format. Of course, if your application is being injected in this conventional way