Core defense mechanisms against security attacks on web applications
Download as PPTX, PDF2 likes1,338 views
The document outlines core defense mechanisms against security attacks on web applications, emphasizing the need for handling user input, user access, and session management due to the inherent risks of untrusted data. It discusses various approaches to input validation, such as rejecting known bad input, accepting known good input, and implementing sanitization and safe data handling. The importance of multi-step validation and handling attackers is also highlighted to ensure robust application security.
Core defense mechanisms against security attacks on web applications
- 1. Core Defense Mechanisms against security attacks on Web Applications BY KARAN NAGRECHA SMARTSENSE CONSULTING SOLUTIONS PVT. LTD. HTTP://WWW.SMARTSENSESOLUTIONS.COM/
- 2. What defense mechanisms are we currently using in our applications?
- 3. Most common Security issues All user input is untrusted User Authentication Handling user access to the application’s data and functionalities. Session Management Privileges escalation Use of ready made code components to handle various functionalities in the app such as authentication, page modules, message/chat board etc. Lack of proper validation, design flow and functionality flow. Error and exception handling mechanism
- 4. Most common Security issues Blocking mechanism Common or easy to guess login credentials for Admin and other users. Poor password requirement and forgot/change password management Use of old version of database and/or framework. Process of untrusted data. How our system processes the received untrusted data
- 5. Core Defense Mechanisms Handling user access to the application’s data and functionality to prevent users from gaining unauthorized access. Handling user input to the application’s functions to prevent malformed input from causing undesirable behavior. Handling attackers to ensure that the application behaves appropriately when being directly targeted, taking suitable defensive and offensive measures to frustrate the attacker. Managing the application itself by enabling administrators to monitor its activities and configure its functionalities.
- 6. Handling User Access Most web applications handle user access using a trio of interrelated security mechanisms: 1. Authentication 2. Session Management 3. Access Control
- 7. Authentication: The authentication mechanism is logically the most basic dependency in an application’s handling of user access. Authenticating a user involves establishing that the user is in fact who he claims to be. Without this facility, the application would need to treat all users as anonymous. The majority of today’s web applications employ the conventional authentication model, in which the user submits a username and password, which the application checks for validity. For security critical application this basic login model is supplemented by additional credentials and a multistage login process. Despite all these features authentication mechanism suffers from a wide range of defects in both design and implementation.
- 8. Session Management The next logical task in the process of handling user access is to manage the authenticated user’s session. The user accesses various pages and functions, making a series of HTTP requests from his browser. At the same time, the application receives countless other requests from different users, some of whom are authenticated and some of whom are anonymous. The application needs a way to identify and process the series of requests that originated from each unique member. All web applications meet this requirement by creating a session for each user. The session management mechanism is highly dependent on the security of its tokens. And the majority of attacks against it seek to compromise the tokens issued to other users. Main vulnerability arise from defects in how tokens are generated, enabling an attacker to guess the tokens issued to other users and defects in how tokens are handled.
- 9. Access Control The access control mechanism usually needs to implement some fine-grained logic, with different consideration being relevant to different areas of the application and different types of functionality Due to complex nature of typical access control requirements, this mechanism is a frequent source of security vulnerabilities that enable an attacker to gain unauthorized access to data and functionality. Developers often make flawed assumptions about how users will interact with the application and frequently make oversight by omitting access control checks from some application functions Same checks need to be repeated for each item of functionality.
- 10. Handling User Input The fundamental security problem in web application is all user input is untrusted. A huge variety of attacks against web application involve submitting unexpected input, crafted to cause behavior that was not intended by application’s designers. Input-based vulnerabilities can arise anywhere within an application’s functionality. “Input Validation” is often cited as the necessary defense against these attacks, however, no single protective mechanism can be employed everywhere and defending against malicious input is often not as straightforward as it sounds.
- 11. Handling User Input In many cases, an application may be able to impose very strict validation checks on a specific item of input. For example, a username submitted to a login function may be required to have a maximum length of eight characters and contain only alphabets. However for this item, restrictions still can be feasibly imposed. The data should not exceed a reasonable length limit (such as 50 characters) and should not contain any HTML markup. In some situations, an application may need to accept arbitrary input from user. The application may need to store this input into a database, write it to disk and display it back to users in a safe way. It can not simply reject the input just because it looks potentially malicious.
- 12. Handling User Input There are some input which began their life on the server and that are sent to the client so that the client can transmit them back to the server on subsequent request. This includes items such as cookies and hidden form fields, which are not seen by ordinary users of the application but which an attacker can of course view and modify. In these cases application can perform very specific validation of the data received. For example, a parameter might be required to have one of a specific set of known values, such as a cookie indicating the user’s preferred language.
- 13. Handling User Input Furthermore, when an application detects that server-generated data has been modified in a way that is not possible for an ordinary user with a standalone browser, this often indicates that the user is attempting to probe the application for vulnerabilities. In these cases application should reject the request and log the incident for potential investigation.
- 14. Approaches to Input Handling Reject Known Bad Accept known Good Sanitization Safe Data Handling Semantic Checks Boundary Validation Multistep Validation and Canonicalization
- 15. Reject Known Bad This approach typically employs a blacklist containing a set of literal strings or patterns that are known to be used in attacks. The validation mechanism blocks any data that matches the blacklist and allows everything else. This is the least effective approach to validate user inputs for two main reasons. First, a typical vulnerability in a web application can be exploited using a wide variety of input, which may be encoded or represented in various ways. Except in the simplest of cases, it is likely that a blacklist will omit some patterns of input that can be used to attack the application.
- 16. Reject Known Bad Second, techniques for exploitation are constantly evolving. Novel methods for exploiting existing categories of vulnerabilities are unlikely to be blocked by current blacklists. Many blacklist-based filters can be bypassed by making trivial adjustment to the input that is being blocked. For example If SELECT is blocked try, SeLecT If or 1=1– is blocked try or 2=2— If alert(‘xss’) is blocked, try prompt(‘xss’)
- 17. Reject Known Bad In other cases, filters designed to block specific keywords can be bypassed by using nonstandard characters between expression to disrupt the tokenizing performed by the application. For example: SELECT/*foo*/username,password/*foo*/FROM/*foo*/users<img%09onerror=alert( 1) src=a> Finally numerous blacklisted filters, particularly those implemented in web application firewalls, have been vulnerable to NULL byte attacks. Because of the different ways in which strings are handled. %00<script>alert(1)</script> - Inserting a null byte before any blocked expression can cause some filters to stop processing inputs.
- 18. Accept Known Good This approach employs a whitelist containing a set of literal strings or patterns or a set of criteria, that is known to match only benign input. The validation mechanism allows data that matches the whitelist and blocks everything else. In cases, where this approach is feasible, it is regarded as the most effective way to handle potentially malicious input. However, in numerous situations an application must accept data for processing that does not meet any reasonable criteria for what is known to be “good”.
- 19. Accept Known Good For example, some people’s name contain an apostrophe or hyphen. These can be used in attacks against databases, but it may be a requirement that the application should permit anyone to register under his or her real name. Hence, although it is often extremely effective, the whitelist-based approach does not represent an all-purpose solution to the problem of handling user input.
- 20. Sanitization This approach recognizes the need to sometimes accept data that cannot be guaranteed as safe. Instead of rejecting this input, the application sanitizes it in various ways to prevent it from having any adverse effects. Potentially malicious characters may be removed from the data, leaving only what is known to be safe, or they may be suitably encoded or escaped before further processing is performed. The usual defense against cross-site scripting attack is to HTML-encode dangerous characters before these are embedded into pages of web application. Like < - >, > - <, = - &qual etc.
- 21. Safe Data Handling Many web application vulnerabilities arise because user-supplied data is processed in unsafe ways. Vulnerabilities often can be avoided not by validating the input itself but by ensuring that the processing that is performed on it is inherently safe. In some situation safe programming methods are available that avoid common problems. For example, SQL injection attacks can be prevented through the correct use of parameterized queries for database access. In other situations, application functionalities can be designed in such a way that inherently unsafe practices, such as passing user input to an operating system command interpreter, are avoided.
- 22. Semantic Checks The defense described so far all address the need to defend the application against various kinds of malformed data whose content has been crafted to interfere with the application’s processing. However, with some vulnerabilities the input supplied by the attacker is identical to the input that an ordinary, nonmalicious user may submit. What makes it malicious is the different circumstances under which it is submitted For example, an attacker might seek to gain access to another user’s bank account by changing an account number transmitted in a hidden form field. No amount of semantic validation will distinguish between the user’s data and the attacker’s. To prevent unauthorized access, the application needs to validate that the account number submitted belongs to the user who has submitted it.
- 23. Boundary Validation Given the wide range of functionality that the applications implement, and the different technologies in use, a typical application needs to defend itself against a huge variety of input-based attacks, each of which may employ a diverse set of crafted data. It would be very difficult to devise a single mechanism at the external boundary to defend against all these attacks. Many application functions involve chaining together a series of different types of processing. A single piece of user-supplied input might result in a number of operations in different components, with the output of each being used as the input for the next. A skilled attacker may be able to manipulate the application to cause malicious input to be generated at a key stage of the processing, attacking the component that receives this data.
- 24. Boundary Validation It would be extremely difficult to implement a validation mechanism at the external boundary to foresee all the possible results of processing each piece of user input. Defending against different categories of input-based attack may entail performing different validation check on user input that are incompatible with one another. For example, preventing cross-site scripting attacks may require the application to HTML- encode the > character as > and preventing command injection attacks may require the application to block input containing the & and ; characters. Attempting to prevent all categories of attack simultaneously at the application’s external boundary may sometimes be impossible.
- 25. Boundary Validation A more effective model uses the concept of Boundary Validation. Here, each individual component or functional unit of the server-side application treats its inputs as coming from a potentially malicious source. Data validation performed at each of these trust boundaries, in addition to the external frontier between the client and server. Each component can defend itself against the specific types of crafted input to which it may be vulnerable. And because the various validation checks are implemented at different stages of processing, they are unlikely to come into conflict with one another.
- 27. Boundary Validation This figure illustrates a typical situation where boundary validation is the most effective approach to defending against malicious input. The user login results in several steps of processing being performed on user-supplied input, and suitable validation is performed at each step. The application receives the user’s login details. The form handler validates that each item of input contains only permitted characters, is within a specific length limit, and does not contain any known attack signatures. The application performs a SQL query to verify the user’s credentials. To prevent SQL injection attacks, any characters within the user input that may be used to attack the database are escaped before the query is constructed.
- 28. Boundary Validation If the login succeeds, the application passes certain data from the user’s profile to a SOAP service to retrieve further information about her account. To prevent SOAP injection attacks, any XML, metacharacters within the user’s profile data are suitably encoded. The application displays the user’s account information back to the user’s browser. To prevent cross-site scripting attacks, the application HTML-encodes any user-supplied data that is embedded into the returned page. If variations on this functionality involved passing data to further application components, similar defenses would need to be implemented at the relevant trust boundaries. Ex: If a failed login caused the app to send a warning email to the user, any user data in that email must be checked for SMTP injection attack.
- 29. Multistep Validation and Canonicalization A common problem encountered by input-handling mechanisms arises when user- supplied input is manipulated across several steps as part of the validation logic. If this process is not handled carefully, an attacker may be able to construct crafted input that succeeds in smuggling malicious data through the validation mechanism. One version of this problem occurs when an application attempts to sanitize user input by removing or encoding certain characters or expression. For Example, an application may attempt to defend against some cross-site scripting attacks by stripping the expression: <script>
- 30. Multistep Validation and Canonicalization However, an attacker may be able to bypass the filter by supplying the following input: <scr<script>ipt> When the blocked expression is removed, the surrounding data contracts to restore the malicious payload, because the filter is not being applied recursively. Similarly if more than one validation step is performed on user input, an attacker may be able to exploit the ordering of these steps to bypass the filters. For example: if the application first removes ../ recursively and then removes .. recursively, the following input can be used to defeat the validation: …./
- 31. Multistep Validation and Canonicalization A related problem arises in relation to data canonicalization. When input is sent from the user’s browser, it may be encoded in various ways. These encoding schemes exists exist so that unusual characters and binary data may be transmitted safely over HTTP. Canonicalization is the process of converting or decoding data into a common character set. If any canonicalization is carried out after input filters have been applied, an attacker may be able to use a suitable encoding scheme to bypass the validation mechanism. For example, an application may attempt to defend against some SQ injection attack by blocking input containing the apostrophe character.
- 32. Multistep Validation and Canonicalization However, if the input is subsequently canonicalized, an attacker may be able to use double URL encoding to defeat the filter. For example: %2527 When this input is received, the application server performs its normal URL decode, so the input becomes: %27 This does not contain an apostrophe, so it is permitted by the application’s filters. But when the application performs a further URL decode, the input is converted into an apostrophe, thereby passing the filter. If the application strips the apostrophe instead of blocking it, and then performs further canonicalization, the following bypass my be effective. %2727
- 33. Multistep Validation and Canonicalization It is worth noting that the multiple validation and canonicalization steps in these cases need not all take place on the server side of the application. For example, in the following input several characters have been HTML encoded: <i frame src=ja vascript: alert( 1)> If the server side application uses an input filter to block certain JavaScript expression and characters, the encoded input may succeed in bypassing the filter. However, if the input is then copied into the application’s response, some browser perform an HTML decode of the src parameter value, and the embedded JavaScript executes.
- 34. Multistep Validation and Canonicalization In addition to the standard encoding schemes that are intended for use in web applications, canonicalization issues can arise in other situations where a component employed by the application converts data from one character set to another. For example, some technologies perform a “best fit” mapping of characters based on similarities in their printed symbol. Here, the character << and >> may be converted into < and >. This behavior can often be leveraged to smuggle blocked characters or keywords past an application’s input filters.
- 35. Handling Attackers Anyone designing an application for which security is remotely important must assume that it will be directly targeted by dedicated and skilled attackers. A key function of the application’s security mechanism is being able to handle and react to these attacks in a controlled way. Below tasks are typically included in handling attackers: 1. Handling errors 2. Maintaining audit logs 3. Alerting administrators 4. Reacting to attacks
- 36. Handling Errors However careful an application’s developers are when validating user input, it is virtually inevitable that some unanticipated errors will occur. Errors resulting from the actions of ordinary users are likely to be identified during functionality and user acceptance testing. However, it is difficult to anticipate every possible way in which a malicious user may interact with the application, so further errors should be expected when the application comes under attack. A key defense mechanism is for the application to handle unexpected errors gracefully and either recover from them or present a suitable error message to the user. In a production context, the application should never return any system-generated messages or other debug information in response.
- 37. Handling Errors Unwanted error messages can greatly assist malicious users in furthering their attacks against the application. In some situations, an attacker can leverage defective error handling to retrieve sensitive information within the error messages themselves, providing valuable channel for stealing data from the application. Most web development languages provide good error-handling support throughout try-catch blocks and checked exceptions. Application code should make extensive use of these constructs to catch specific and general errors and handle them appropriately.
- 38. Handling Errors Most application servers can be configured to deal with unhandled errors in customized ways, such as by representing an uninformative error message. In Java platform , you can configured customized error messages using the error- page element of the web.xml file. You can use the exception-type node to specify an HTTP status code. You can use the location node to set custom page to be displayed in the event of the specified error. In Apache, custom error pages can be configured using the ErrorDocument directive in httpd.conf: ErrorDocument 500 /generalerror.html
- 39. Handling Errors In Microsoft IIS, you can specify custom error pages for different HTTP status codes using the Custom Errors tab on a website’s Properties Tab. A different custom page can be set for each status code, and on a per directory basis if required.
- 40. Maintaining Audit Logs Audit logs are valuable primarily when investigating intrusion attempts against an application. Following such incident, effective audit logs should enable the application’s owners to understand exactly what has taken place, which vulnerabilities were exploited, whether the attacker gained unauthorized access to data or performed any unauthorized actions, and, as far as possible provide evidence of the intruder’s identity. In any application for which security is important, key event should be logged as a matter of course. At a minimum, these typically include the following:
- 41. Maintaining Audit Logs All events relating to the authentication functionality, such as successful and failed login, and change of password. Key transactions, such as credit card payments and fund transfers. Access attempts that are blocked by the access control mechanisms. Any requests containing known attack strings that indicate overtly malicious intentions. In many security-critical applications, such as those used by online banks, every client request is logged in full, providing a complete forensic record that can be used to investigate any incident.
- 42. Maintaining Audit Logs Effective audits logs typically record time of each event, the IP address from which the request was received and the user’s account (if authenticated). Such logs need to be strongly protected against unauthorized read or write access. An effective approach is to store audit logs on an autonomous system that accepts only update messages from the main application. In some situations, logs may be flushed to write-once media to ensure their integrity in the event of a successful attack. Poorly protected audit logs will provide an attacker host of sensitive information such as session tokens and request parameters.
- 43. Alerting Administrators Audit logs enable an application’s owner to retrospectively investigate intrusion attempts and, if possible, take legal action against the perpetrator. However, in many situations it is desirable to take much more immediate action, in real time. For example, administrators may block the IP address or user account an attacker is using. In extreme cases, they may even take the application offline while investigating the attack and taking remedial action. In most situations, alerting mechanisms must balance the conflicting objectives of reporting each genuine attack reliably and of not generating so many alerts that these come to be ignored.
- 44. Alerting Administrators A well-designed alerting mechanism attack can use a combination of factors to diagnose that a determined attack is underway and can aggregate related events into a single alert where possible. Events monitored by alerting mechanisms often include the following: 1. Usage anomalies, such as large numbers of requests being received from a single IP address or user, indicating a scripted attack. 2. Business anomalies, such as an unusual number of funds transfers being made to or from a single bank account. 3. Requests containing known attack strings. 4. Requests where data that is hidden from ordinary users has been modified.
- 45. Alerting Administrators Some of these functions can be provided reasonably well by off-the –shelf application firewalls and intrusion detection products. These typically use a mixture of signature and anomaly based rules to identify malicious use of the application and may reactively block malicious requests as well as issue alerts to administrators. Web application firewalls usually are good at identifying the most obvious attacks, where an attacker submits standard attack strings in each request parameter. However many attacks are more subtle than this. For example, perhaps they modify the account number in a hidden field to access another user’s data, or submit requests out of sequence to exploit defects in the application’s logic.
- 46. Alerting Administrators In these cases, a request submitted by an attacker may be identical to that submitted by a normal user. What makes it malicious are the circumstances under which it is made. In any security-critical application, the most effective way to implement real time alerting is to integrate this tightly with the application’s input validation mechanisms and other controls. For example, if a cookie is expected to have one of a specific set of values, any violation of this indicates that its value has been modified in a way that is not possible for ordinary users of the application.
- 47. Alerting Administrators Similarly, if a user changes an account number in a hidden field to identify a different user’s account, this strongly indicates malicious intent. The application should already be checking for these attacks as a part of its primary defense. These protective mechanisms can easily hook into the application’s alerting mechanisms to provide indicators of malicious activity Because these checks have been tailored to the application’s actual logic, with a fine-grained knowledge of how ordinary users should be behaving, they are much less prone to false positives than any off-the-shelf solutions.
- 48. Reacting to Attacks In addition to alerting administrators, many security-critical applications contain built-in mechanisms to react defensively to users who are identified as potentially malicious. Because each application is different, most real-world attacks require an attacker to probe systematically for vulnerabilities, submitting numerous requests containing crafted input design to indicate the presence of various common vulnerabilities. At some point, an attacker working systematically is likely to discover these defects. For this reason, some applications take automatic reactive measures to frustrate the activities of an attacker who is working in this way.
- 49. Reacting to Attacks For example, they might respond increasingly slowly to attacker’s requests or terminate the attacker’s session, requiring him to log in or perform other steps before continuing the attack. Reacting to apparent attackers is not a substitute for fixing any vulnerabilities that exist within the application. However, in the real world placing further obstacles in the way of an attacker is an effective defense-in-depth measure that reduces the likelihood that any residual vulnerabilities will be found and exploited.