WAF - Typical Detection & Protection Techniques

WAF - Web Application Firewalls is a new breed of information security technology that offers protection to web sites and web applications from malicious attacks. As the name suggests, WAF solution is intended scanning the HTTP and HTTPS traffic alone. The WAF solutions have evolved over the last few years and are capable of preventing attacks that network firewalls and intrusion detection systems can't. The WAF offering typically comes in the form of a packaged appliance, i.e. with a purpose built hardware and a software running on it and is plugged in to the network. Different appliances offer different level of deployment capabilities, like, active / passive modes, support for High Availability,etc.

Different vendors have come up with various techniques to detect and protect web applications of the enterprise and thus the capabilities of the solution differ. However, at a minimum these devices offer the following detection and protection capabilities:

Detection Techniques

Normalization techniques

Web applications of those days were simple and mostly was comprising of the HTML content. Various tools and solutions have emerged to leverage the HTTP protocol for use by various applications to receive and send complex data including encoded binary data of higher volumes and also extend the use of the HTTP methods. Hackers also leverage these techniques to attack a web application. This calls for the WAF device should have the ability to use a technique to transform the input data into a normalized form, so that the same can be inspected for potential malicious content that could be leverage to perform an attack.

Signature Based Detection

This technique involves use of a string or regular expression based match against the incoming traffic for a specific signature and thus detecting a potential attack. For this purpose, the need to maintain a database of such attack signature is essential. Most popular WAF solution vendors maintain their own databases, whereas others subscribe to such databases.These databases need frequent updates to take into account the signatures used in recent attacks elsewhere.

Rule Based Detection 

Rule based Detection technique is similar to Signature Based Detection, but it allows use of a more complex logic. For instance, even if a signature match is detected, it can be further subjected to certain other conditions, like if the data is from a trusted source, the traffic may still be allowed to pass through with or without appropriate alerts and triggers for manual inspection. While the WAF solution is shipped with the standard rules, the same would be configurable to meet the security needs of the customer. The standard rules may also be part of the signature / rule database as may be maintained or subscribed to by the vendor

APIs for Extensibility

Despite the standard signature and rule based detection techniques, the actual deployment scenario at the customer site may require customization of the techniques used in detection. WAF solutions vendors usually support this need by offering extensible APIs, plug-ins, or scripting. These extensiblity options if not appropriately secured, can be exploited by hackers too.


Protection Techniques

Brute Force Attacks Mitigation

These attacks use automated scripts that attempt to login to the web application with common user name and passwords. The attacks usually originate from a large number of sources consisting of both legitimate web servers and private home computers. Once a username and password is successfully guessed, the hackers or their scripts / tools use the gained admin credentials for the next stage of attacks. Given that the user name passwords follow stricter rules and thus these attack is most likely to fail in guessing the valid credentials, but these attacks generate unduly high traffic, which will result in resource drain and in turn affect the availability of the web application.

Protection from Cookie Poisoning

Cookie Poisoning attacks involve the modification of the contents of a cookie (personal information stored in a Web user's computer) in order to bypass security mechanisms. Using cookie poisoning attacks, attackers can gain unauthorized information about another user and steal their identity. Cookie poisoning is in fact a Parameter Tampering attack, where the parameters are stored in a cookie. In many cases cookie poisoning is more useful than other Parameter Tampering attacks because programmers store sensitive information in the allegedly invisible cookie. Most WAF solutions offer protection from Cookie poisoning by facilitating the signing and / or encryption of cookies, virtualizing the cookies or a custom protection mechanism as the specific web application may demand.

Session Attacks Mitigation

Session store is an important component of a web application and this store is used to share some of the common parameters pertaining to the user and the specific session across various actions within the application. Thus the session data is a key component that is used to secure the web applications. The hackers on the other hand try various techniques to hijack the session or tamper the session parameters. While tampering the parameter values is similar to Cookie Poisoning, Session Hijacking is stealing the session identifier and simulating requests from different sources with the stolen session identity. WAF solutions provide protection to session hijacking by signing and / or encrypting the session data and also linking the session identifier with the originating client.

Injection Attack Protection

An SQL injection attack is insertion of a SQL query via the input data from the client to the application. A successful SQL injection attack can read sensitive data from the database, modify database data, or shutdown the server. Similarly operating system and platform commands can often be used to give attackers access to data and escalate privileges on back-end servers Remote File Inclusion attacks allow malicious users to run their own PHP code on a vulnerable website to access anything that the PHP program could: databases, password files, etc. Most WAF solutions using the normalization technique and the signature and rule database would be able to deny requests carrying such data, command or instruction that could lead to any of the injection attacks.

DDoS Protection

Distributed Denial of Attack is a common technique used by hackers to impair the availability of a website or application by directing unusually huge traffic against the site or application. This will result in all the computing resources used up and eventually leading to the site not being available at all. The WAF solutions making use of the normalization techniques and the signature and rule databases would be able to block such requests. Some common techniques used by the WAF solutions are to have a check on the content length and by evaluating the number of requests or sessions from the same originating client within a given time period.


Obviously, what is listed above are most common detection and protection techniques that any WAF solution would offer. But vendors are constantly improving these techniques and thus adding more detection and protection features. This has to be a constant endeavor as the hackers on the other hand are also coming up with newer techniques to exploit various vulnerabilities.

REST Services - Security Best Practices

As most of us know, REST (Representational State Transfer) is an architectural principle and is gaining increasing reckoning amongst architects for the inherent advantages that it offers. REST does recommend the use of standards such as HTTP, URI, XML and JSON and formats such as GIF, MPEG, etc. Twitter, iPhone apps, Google Maps, and Amazon Web Services (AWS) demonstrate heavy use of REST services. The basic tenets of REST is statelessness and is all about utilizing the HTTP commands GET, PUT, POST, DELETE as outlined in the HTTP RFC.


Obviously, Architects see some key advantages with the REST services, and so REST implementation becomes an important consideration in responsive, service oriented applications. Let us have a recap of some of the key advantages as below:

• The resources can be uniquely identified using URI and facilitates interconnection of these resources.
• Resource manipulation is accomplished using the standard HTTP verbs, viz GET, PUT, POST, DELETE
• The data payload is minimal and thus offers the capacity and efficiency benefits.
• Easier implementation offers shorter learning curve, maintainability and time to market advantage.
• Increased support from the JavaScript offers the client side computing benefits and thus improve the responsiveness.

Needless to mention, there are certain disadvantages too with the REST Services and here are some:

• Prone for same level of threats and vulnerabilities as the HTTP and Web
• Improper use of the HTTP commands could lead to problems and complicate the design.
• Relies on very few standards.

Some of the security challenges with REST Service implementations are outlined below:

Chained trust is challenging for web service implementations and the situation is no different with REST. Unlike in case of SOAP, standards like WS-Security, SAML cannot be used in case of REST services. This call for relying on a combination security implementations which are specific to different implementations. Here are some such security implementations, which in combination may help overcome this concern:

• Use Digital Certificates for authenticating the server and the user. 
• Pass the user's identity from server to server and necessary validation and authorization at the data source.

Cross site request forgery (CSRF) attacks, which attempt to force an authenticated user to execute functionality without their knowledge. Being stateless, REST is inherently vulnerable to CSRF attacks. The work arounds for this security concern are:

• Use of a custom header - Setting a custom header such as X-XSRF header is known to be a solution for this concern. The endpoints receiving the REST service requests would reject or drop such requests if the intended custom header is not part of the request. It is to be noted that this is not a fool proof technique, but at the same time offers some bit of protection than nothing.
• Another approach is to deviate from the basic tenets of REST and maintaining state, in which case a token can be generated and maintained to authenticate the requests, so that requests carrying an invalid or no tokens can be dropped or rejected.

While the above are just an example of the concerns, REST services being based on HTTP specifications is prone to all the security vulnerabilities as that of a web application. Thus REST implementation while it is the easier choice due to its advantages listed above, should also be implemented with due considerations to some or all of the following security best practices:

• All data must be sent over HTTPS and this will ensure securing of the data in transit.
• Use of PKI or HTTP Digest Authentication for authentication.
• Always perform authorization for every request upon receipt. 
• Scan HTTP headers, query strings and POST data and look for reasons to reject a request.
• Don't combine multiple resources with a single URI, always uniquely identify each resource, so that the security implementation can be simple and relevant to the specific resource.
• Always perform validation of the JSON / XML data.
• Ensure appropriate use of the HTTP commands for managing the resources and enable selective restriction of these commands.
• Design URIs to be persistent. If a URI needs to change, honor the old URI and issue a redirect to the client.
• Caching should generally be avoided where possible and sensitive data should never be cached.
• When developing REST solutions, care needs to be taken not to create URIs that contain sensitive information. 
• The requester should be authenticated and authorized prior to completing an access control decision. 
• All access control decisions shall be logged. 
• Code as if protecting the application.

Here are certain useful readings on securing the REST services:

• REST vs. SOAP: How to choose the best Web service
• Enabling Message Security for RESTful Services
• Securing RESTful Web Services with OAuth2
• Securing RESTful services
• REST Assessment Cheat Sheet
• Configuring Spring Security for a RESTful Web Services
• Comparison of Security Techniques for RESTful Services

Webservices Security: Potential Threats to Combat

Web Services is one of the primary method of implementing SOA in highly distributed enterprise computing environments where not only the enterprise applications need to be integrated with internal applications, but also with the external systems built and operated by various business partners. That requires such services exposed beyond the trust boundaries of the enterprise and thus increasing the security threat landscape.

Securing webservices is more complicated than any other end user systems, as the webservices are built as the conduit between systems rather than human users. Most of us are very familiar with the first line of defense, namely authentication, data integrity, confidentiality and non repudiation. These are certainly critical security concerns, but there are well established tools and practices that help address these security issues. But, this it not just be enough to be contempt with solving these concerns, as the services are no longer constrained within the trust boundaries.

While other types of applications have executables that act as an outer layer and protects the application's internals, webservices don't have such outer layer and thus expose the internals to potential unforgiving hackers on the internet or intranet. Testing and securing webservices require a toolkit with abilities to act like a client or for that matter its proxy and being able to intercept, transform or manipulate the messages that are being exchanged. Having said that, the toolkits alone would not guarantee a complete solution to combat the security exposure of the webservices. There need to be an understanding of the application, context, trust boundaries etc, which will help to enumerate the potential threats that need to be managed and then use the toolkits.

In this blog, let us have a look at the potential threat categories beyond the first line of defense that an organization should be aware of and be prepared to combat. As always, the attempt is to come up with the most significant threats and not to produce an exhaustive list of such threats. Determination of the specific threats under each category requires an analysis of the application and its internals in line with the trust levels.


Privilege Escalation

Virtually all attacks attempt to do something the attacker is not privileged to do. The hacker wants to somehow leverage whatever limited privilege he has, and turn it into higher ("elevated") privilege, as a result of potentially flawed authentication and authorization mechanisms. Sometimes, hackers would exploit vulnerabilities in the internal components of the service, be it custom coded or third party components and thus gaining privileges for remote code execution or database manipulation. It is obvious that the consequences of such breach could be severe leading to financial and non financial damages.

While the protection for such vulnerabilities depends on the specifics of the application and its architecture, as a general best practice, the authentication and authorization needs of each of the internal components shall be carefully established based on the least privilege principle, by considering additional contextual information like the client, location, or network in addition to the basic credentials and by implementing multiple levels of authentication within the service components can alleviate this category of threats. When third party components or run times are used, it is important to constantly apply the security patches that the vendors may release.


Denial of Service

The interoperable and loosely-coupled web services architecture, while beneficial, can be resource-intensive, and is thus susceptible to denial of service (DoS) attacks in which an attacker can use a relatively insignificant amount of resources to exhaust the computational resources of a web service. Denial of Service attack is aimed at causing impact on the availability of the underlying network, compute or storage resources for the legitimate service consumers. Given that webservices are typically used in high availability enterprise integration scenarios, even a smaller magnitude of DoS attach could cause sever disruption in all the connected systems and leading to breach of SLAs with partners and thus at times leading to financial damage as well.

The effects of these attacks can vary from causing high CPU usage, to causing the JVM to run out of memory. Clearly the latter is a critical vulnerability. Protection for DoS can be implemented at different levels with a view to ensure legitimate of use of the underlying resources. Some of the techniques used to combat DoS attacks are to implement various algorithms to restrict access to critical internal components to legitimate requests and rejecting the rest. For instance, the input message size limits can be validated in line with the speciific service method and if the requests carry an unusually large xml messages than expected, such requests can be rejected at the network layer itself. Tools and appliances are available to combat the DoS attacks, but how such tools and appliances are setup and configured would depend on the specific needs.


Spoofing

Spoofing attacks are successful when one entity in a transaction trusts another entity. If an attacker knows about the trust, they can exploit it by masquerading as the trusted party. This can also be masquerading the additional contextual information which is used in authentication or in request processing. The most common of such information are SOAPAction and client IP. There are various ways to exploit credentials or spoof the source of messages. These include credential forgery, session hijacking and impersonation attacks. The services shall be designed to appropriately validate such information in isolation and in combination with other related information, so as to establish the request is legitimate.

Repudiation

An important web services security requirement is nonrepudiation. This requirement prevents a party from denying it sent or received a message. The way to implement this is using Xml Digital Signatures. For example, if I sent a message which is signed with my private key, I cannot later deny that I sent it. This concern arise when the web service does not bind the client to their actions using appropriate techniques or due to flawed implementation of auditing and logging requirements. Data inconsistency is one of the common outcome of this threat and could lead to sever damages to the enterprise.

A combination of the protection measures against various threat categories would help combat this threat. For instance, an adequate protection from spoofing, protecting the messages while in transit coupled with appropriate logging and audit implementations would help minimize the risks arising out of this threat.


Information Privacy

As web services are typically implemented as part of a complex system and have access to a large amount of potentially sensitive information, it is important to ensure that access to the information is restricted. The transfer of the data should also be secured to prevent eavesdropping and sniffing threats. Privacy or confidentiality concerns with webservices is no different than that in any other system. As such, the information disseminated through the information has to be reviewed in line with the organization's information sensitivity policy and apply policies and rules to ensure that when to allow a specific request have access to such information. This will involve not only appropriately defining the authorization rules for the clients and users, but also carefully considering the information or parameters that are received as part of the request message


Message Tampering

Webservice messages, both request and responses if not appropriately protected can be tampered using various attack methods. Web services being a component of a complex distributed enterprise system with integration with multiple partner systems throws open the possibility of message tampering as it is exposed beyond the boundaries with multiple communication paths. Attacks under this threat category include man-in-the-middle attacks and implanting trojans and malwares. As with the other threats, this can also cause severe damages. Compromise under this category may also mean a compromise in one or more other threat categories. For instance, a tampered input message might lead to spoofing of identity and thus compromising the information privacy, etc.


To conclude, as the protection measures are evolving on the one side, newer threats are also emerging and the security professionals need to have a continuous engagement, and have an appropriate security or threat management framework implemented to combat the existing and emerging threats. Periodical security audits shall be supplemented with a formal security testing with necessary toolkits in place. All said and done, the extent of protection should depend on the organization's risk policies and risk appetite, the critical nature of the webservices and the trust boundaries.

---

Scalability

When we talk about the scalability for a web application, it is quite common for us to think of load balanced web farms. This obviously will require the application session state be managed using one of the OutProc options. Depending the utilization of the session state data and the implementation approach, the state server (be it state service or SQL server) may soon hit the scalability / performance limits and become a bottleneck.

This prompted me to think about possible scalability and availability solutions for the State Server. It is again possible to have a load balanced farm of servers to serve the session state requests. But, this requires the state information is replicated across all such servers, so that the information will always be available in across all the load balanced state servers. Obviously this is additional overhead. There are third party tools(like scalenet) to have the session and cache information replicated across multiple servers.

As I was looking for an alternative solution, just came across this Best Practices article on state management published by Microsoft. This article suggests a simple approach of session partitioning using the PartitionResolver Interface and determining the partitioned server using a key derived from the session id.

If any of you have implemented this or any other approach, do post it here.