Using a Service Gateway to Protect against the OWASP Top 10

The Open Web Application Security Project (OWASP) maintains and publishes an oingoing list of top ten threats to web applications. With some of exceptions, the threats listed in the OWASP top ten can be applicable to any service, be it a web application, REST service, SOAP service or custom application. It is interesting to note that while there are changes to the bottom five threats, the top five threats remain unchanged since 2007. That is, despite increased awareness and adoption of security technologies, our top application vulnerabilities are essentially unchanged over the last three years or so!

Why is this the case? One reason is that security policy enforcement remains tightly coupled to applications, making security a hard problem for the average developer. In fact, the phrase 'tight coupling' may not even go far enough to describe the problem. A better way to put it is that application code or business logic is irrevocably enlaced with security processing. The same code processing a purchase order or rendering HTML content is probably also performing a wide range of security processing such as input validation, digital signature verification, decryption, authentication, access control, authorization and numerous other functions.

This is a problem because, let's face it, as evidenced by the OWASP top ten, software developers aren't security architects; they solve different problems in their day to day jobs. When it comes down to doing code reviews or auditing security policy, the existing security code is bound up with the rest of code. It becomes difficult to figure out where the security processing starts and stops without doing a full code review - and who has time for that?

Are we all Insane?



Based on the most recent OWASP, it appears that we haven't made more than marginal improvements in application security. A famous Einstein quote seems to reflect the situation:

"Insanity: doing the same thing over and over again and expecting different results.” - Einstein



Rather than constantly hound developers to improve input validation or write more secure code maybe there is a better way? Rather than focus on what hasn't worked it's time divide and conquer this problem by moving security away from applications into a dedicated gateway.

Service Gateways: The Art of Decoupling



So what do we mean by decoupling in this context? To the extent possible, we need to stop the trend of irrecovably enlaced security processing and break these functions away from the application server and into a dedicated gateway where they become the responsibility of a security architect, not an application programmer. This means that security processing such as threat defense and trust functions should be the job of a dedicated service gateway not intertwined with the application. With this model, the service gateway provides a virtual endpoint for the real application, be it a SOAP or REST service, and enforces security on the wire. The basic model is shown as follows:



In this model, there is a simple trust relationship between the gateway and the application server. The hard work of threat prevention and trust enablement is done by the gateway and presents only secured messages to the application server. This protection is more than just one way: It is also able to protect clients, especially browsers. It does this by also scanning and cleansing messages as they are returned to clients. This bi-directional control is what allows the gateway to combat some of the OWASP top 10 threats quite effectively, all without lengthy code reviews or micro-managed changes to application logic.

So how can a service gateway provide additional protection against the OWASP Top 10? Let's go through the risks for 2010 and see how these are addressed with Intel® SOA Expressway, Intel's service gateway product.

Threat: A1- Injection

Injection flaws, such as SQL, OS, and LDAP injection, occur when untrusted data is sent to an interpreter as part of a command or query. The attacker’s hostile data can trick the interpreter into executing unintended commands or accessing unauthorized data.




Serivce Gateway Mitigation: Code injection comes in many forms and part of the reason for it stems from weakly typed programming languages such as JavaScript and lack of input validation. Fortunately, common code injection techniques can be easily trapped by a security gateway using a defense in depth approach with multiple layers of protection. Beginning at the very bottom, type checking can be enforced on the wire with XML schema types, but since many schemas are extensible by design this is only the beginning. After type enforcement specific language specific attacks can be scanned for such as SQL Injection and XPath injection. Furthermore, since code injection is context dependent and may include shell injection, LDAP calls, PHP code and other languages (maybe some yet unforeseen) the service gateway provides a full regular expression capability for both required and forbidden regular expressions. This will allow the gateway to trap any possible code injection at the perimeter. The best part is that this sort of input validation is no longer required at the application server. Developers rejoice!

Threat: A2 - Cross-Site Scripting (XSS)



XSS flaws occur whenever an application takes untrusted data and sends it to a web browser without proper validation and escaping. XSS allows attackers to execute scripts in the victim’s browser which can hijack user sessions, deface web sites, or redirect the user to malicious sites.







Service Gateway Mitigation: Combating XSS threats happens with two protection mechanisms – one is keeping the script out in the first place and the second is making sure the script is never sent to a browser, even if it gets stored on the application server somehow. The threat that the script poses is not necessarily to the application server, but to the client who unknowingly executes it. Similar to code injection attacks, a service gateway can scan for tags using the same regular expression mechanism, either on the forward or reverse leg. In other words, for incoming requests, documents or messages, content should be scanned executable scripts (variations of <script>, for instance) and should never be allowed in. However, since the service gateway may not be the only entry point to the application (there may be other data sources, such as internal databases or interfaces), content scanning on the reverse leg, back to the client is required. This protects the client even in cases where a database is hacked and a script is inserted into content to be rendered to a browser. Even in this case, the script will be trapped by the gateway before damaging the client.

Threat: A3 - Broken Authentication and Session Management



Application functions related to authentication and session management are often not implemented correctly, allowing attackers to compromise passwords, keys, session tokens, or exploit other implementation flaws to assume other users’ identities.





Service Gateway Mitigation: The main threat here actually relates back to our initial premise, which is that average developers aren’t security architects and may end up with custom authentication and session management schemes that contain holes. A service gateway can mitigate this threat simply by supporting standards such as WS-Security, SAML and SSL/TLS, all of which provide a very well-understood way of handling authentication, message security, and session protection. Why re-invent the wheel? Standards like these exist to provide a secure foundation for applications. Further, service gateways can also sit in front of applications with weak security design, such as exposed session IDs in query parameters, and provide a secure endpoint that uses a stronger way of handling sessions (such as an embedded encrypted and signed session identifier in the message itself) to the external caller, but maps to the expected way of session management by the application. The best part of this model is that no application changes are required. The service gateway provides the secure façade to an otherwise insecure application. In addition, authentication can be handled at the gateway itself, delegating authentication decisions to existing user-stores and identity management systems and presenting only pre-authenticated requests to application servers. Service gateways can provide secure endpoints for applications in spite of broken application servers.

Threat: A4 - Insecure Direct Object References



A direct object reference occurs when a developer exposes a reference to an internal implementation object, such as a file, directory, or database key. Without an access control check or other protection, attackers can manipulate these references to access unauthorized data.




Service Gateway Mitigation: This threat stems from the fact that authorization for a reduced privileged user is often difficult to implement correctly, especially for individual object handles and especially after a user is already authenticated. A service gateway can mitigate this threat by authorizing users for specific resources and actions at the policy enforcement point, rather than at the application. Due to the fact that the service gateway is a full application level proxy, it can determine for a particular request, such as an HTTP GET, if the target resource (URI + query parameter) is accessible. Moreoever, it may be possible for the service gateway to expose indirect object identifiers that are mapped to direct identifiers at the application, such as an account number or account profile. This model would provide increased controls for authorization for these type of direct references without overly intrusive changes to the application.

Threat: A5 - Cross-Site Request Forgery

A CSRF attack forces a logged-on victim’s browser to send a forged HTTP request, including the victim’s session cookie and any other automatically included authentication information, to a vulnerable web application. This allows the attacker to force the victim’s browser to generate requests the vulnerable application thinks are legitimate requests from the victim.



Service Gateway Mitigation: Cross-Site Request Forgery (CSRF) attacks are particularly malicious because they take advantage of an already authenticated session between a user and a service. You may be wondering, if the request is in fact authenticated, how can one defend against such a threat? The answer is to fundamentally improve the authentication mechanism to prevent this type of request hijacking. In CSRF hijacking occurs by convincing a user to click on or otherwise execute an unanticipated function. A common delivery mechanism for a CSRF attack is an HTTP service call (REST call) represented by a link containing the function or functions that the attacker wants the victim to execute. CSRF works because the user already has a legitimate session with the service, and in many cases, a malicious service call can be deduced because REST service calls use unprotected, visible HTTP headers and query parameters. The good news is that service gateways contain all of the building blocks to mitigate CSRF attacks such as nonce checking, digital signatures, hash checking, and the ability to parse secondary session cookies present in hidden HTTP fields. These building blocks are used to authenticate individual requests based on some unpredictable value or second, per-request hidden authentication cookie. The flip-side of this is that applications must be re-designed to include this extra, protected authentication information for individual requests which means re-tooling applications with stronger authentication protocols from the outset.

Threat: A6 - Security Misconfiguration

Good security requires having a secure configuration defined and deployed for the application, frameworks, application server, web server, database server, and platform. All these settings should be defined, implemented, and maintained as many are not shipped with secure defaults. This includes keeping all software up to date, including all code libraries used by the application.



Service Gateway Mitigation: As the number of applications and services continues to grow within the Enterprise, the chance that one of these components, such as an application server or middleware platform, will be misconfigured will continue to rise. Further, Enterprises that rely on custom operating systems or custom hardware make this problem that much harder on themselves. It is easy to issue a general requirement to keep software up to date and properly configured, but the obvious problem here is that this is a never-ending cycle of continual patch management and re-evaluation. Moreover, as business requirements change, software must change to match. Service gateways can't solve this problem, but they can vastly reduce the scope of what must be configured. By pulling security policies and functions away from application servers and centralizing them, the chance of security misconfiguration can be reduced because the number of systems that contain security processing code is also reduced. In addition, centralizing security policy on the wire means that services that trust the gateway are all configured to share a consistent security policy among them.

A7 - Insecure Cryptographic Storage

Many web applications do not properly protect sensitive data, such as credit cards, SSNs, and authentication credentials, with appropriate encryption or hashing. Attackers may steal or modify such weakly protected data to conduct identity theft, credit card fraud, or other crimes.



Service Gateway Mitigation: Protecting sensitive data with encryption or hashing techniques requires experienced application developers with security expertise. It also involves the proper use of cryptographic tool-kits and an understanding of key management techniques for symmetric and asymmetric encryption algorithms. As far as data protection goes, service gateways can decouple both transport layer and message level data protection away from applications as defined by policy and not code. This effectively moves the problem of defining the data protection policy away from the average developer and into a purpose-built gateway that can apply data confidentiality on any part of the message content, either based on OASIS/W3C standards or custom data protection schemes. In some cases, service gateways can also offer data-at-rest protection by storing encrypted data in a database, completely bypassing the application itself. In this last example, the service gateway is really acting as a security service that can make sensitive data available to applications without actually having to include security processing in those applications.

A8 - Failure to Restrict URL Access

Many web applications check URL access rights before rendering protected links and buttons. However, applications need to perform similar access control checks each time these pages are accessed, or attackers will be able to forge URLs to access these hidden pages anyway.



Service Gateway Mitigation: This threat stems from the use of a basic authentication model that relies on security by obscurity. In this case, the application assumes the protected page or resource cannot be easily found and that access to the page is gated by an authentication challenge. Once the challenge succeeds, the user is given the URL or location of the protected resource. The obvious problem here is that the user can simply save the resource location and skip authentication entirely. The real threat here lies in the case where the attacker steals the location of the protected resources or figures it out through a brute-force attack on likely resource locations. Service Gateways do an excellent job of protecting against these threats as they are based on an explicit white-list policy model and can easily enforce per-request authentication and resource-based authorization. If a specific service endpoint is not explicitly configured in the service gateway, the request will be rejected. This checking applies not only at the HTTP URI and query parameter level, but also to HTTP parameters, such as a SOAP Action or individual XPath expressions that must match the request headers or body. Aside from this white-list behavior, Service Gateways can enforce authentication based on credentials in carried in the message header, such as HTTP Basic Authentication or WS-Security and can also enforce fine-grained authorization based on a combination of a subject, resource and action.

A9 - Insufficient Transport Layer Protection

Applications frequently fail to authenticate, encrypt, and protect the confidentiality and integrity of sensitive network traffic. When they do, they sometimes support weak algorithms, use expired or invalid certificates, or do not use them correctly.



Service Gateway Mitigation: While transport level security in the form of SSL/TLS has been around for awhile, challenges remain with ensuring correct configuration, especially with respect to cipher-suite selection and chain of trust. Service Gateways shine here again as they also act as SSL acceleration and termination points with support for multiple SSL server and client identities. This means that SSL/TLS can be configured in the gateway once in front of existing applications, effectively offloading both the handshake and bulk data processing of the SSL protocol to the gateway. The benefit of this approach is not just performance, but it allows SSL/TLS to be decoupled from back-end application servers and centralizes the cipher suite selection, CA authentication policies and private key storage in a single place where there is less of a chance of misconfiguration

A10 - Unvalidated Redirects and Forwards


Web applications frequently redirect and forward users to other pages and websites, and use untrusted data to determine the destination pages. Without proper validation, attackers can redirect victims to phishing or malware sites, or use forwards to access unauthorized pages.



Service Gateway Mitigation: This category of attack appears to be confined to web applications rather than services in general as the attack is based on a browser redirect. This type of phishing attack can fool a user into thinking a phishing site is a legitimate one and these types of redirects can be prevented by a systematic scan ('spidering') of the web application to look for pages that issue an HTTP redirect command (302-207). This process, however, can be time-consuming and such a scan must be done on all suspected web applications. Service Gateways can mitigate this type of attack in two ways. First, the redirect can be immediately trapped at the gateway itself, preventing it from ever reaching the user, and second, malicious content bearing URLs defined by a regular expression can be trapped when detected in certain parts of the content, such as an HTTP query parameter. In other words, if an application or service doesn't expect to have URLs in parts of it's content, the service gateway can actively scan for URLs and URL-like strings in query parameters and flag these as potential threats.

Conclusion



As we have seen, the OWASP top ten spans covers a large number of application vulnerabilities, and while we can do our best to protect against these at the application itself, this often becomes a practical limitation as the number and complexity of applications continues to grow within the Enterprise. Adding to this is the fact that security processing is tightly coupled to the application, making security policies difficult to audit, manage and change. Service Gateways can help protect against many of the OWASP threats by pulling security processing out of the application into a dedicated gateway where policies can be more easily managed by a security architect, not an application developer.



For more complete information about compiler optimizations, see our Optimization Notice.

Comments

's picture

Interesting post. While I agree that some of these items can (and possibly should) be handled outside the application, many of them WILL require application specific tweaks. These changes will likely be even more specific than per-application, ie. per page/form/field, etc. The premise that you no longer have to have your developers make security decisions would be nice, but in this case, you're just moving the security specific details to an external device managed by someone else. By your own admission, you suppose the security architect will manage this information. This practically will result in confusion between the dev team and the security architect, and either a reasonably secure system that has lots of white-listed corner cases needed by the app handled in 1 central place, or an insecure system where the controls are relaxed so the work can actually be accomplished. Lastly, any of these issues that deal with application data (like #4 DOR) is more time-consuming and error-prone to get right in a device as opposed to the application where the information already resides. I think the right approach is to use the right tool for a given task. The service gateway, IMO, is not the right tool for all these tasks, even though you might could shoehorn it in to get it to work.

's picture

When you rely on advanced and complex regular-expression based defenses, you are almost certainly vulnerable to RegExDOS style attacks. http://msdn.microsoft.com/nl-nl/magazine/ff646973%28en-us%29.aspx