Web Application Threat and Web Application Firewall (WAF)
Web Application Threat and Web Application Firewall (WAF)
In this article, we'll discuss web application security in general and why you should consider using WAFs to better protect your web applications.
Join the DZone community and get the full member experience.Join For Free
Web-based applications and services have changed the landscape of information delivery and exchange in today’s corporate, government, and educational arenas. Ease of access, increased availability of information, and the richness of web services have universally increased productivity and operational efficiencies. These increases have led to heavier reliance on web-based services and greater integration of internal information systems and data repositories with web-facing applications.
While motivations of attackers against a victim’s corporate and organizational assets remain the same (e.g., financial, intellectual property (IP), identity theft, services disruption, or denial of service), web applications enable a whole new class of vulnerabilities and exploit techniques such as SQL injection, cross-site scripting (XSS), and cross-site request forgery.
One technology that can help in the security of web application infrastructure is a web application firewall. A web application firewall (WAF) is an appliance or server application that watches HTTP/HTTPS conversations between a client browser and web server at layer 7. The WAF then has the ability to enforce security policies based upon a variety of criteria including signatures of known attacks, protocol standards, and anomalous application traffic.
Web Application Security
Web application security is a branch of Information Security that deals specifically with the security of websites, web applications, and web services. At a high level, web application security draws on the principles of application security but applies them specifically to Internet and Web systems.
Different Aspects of Web Security
- Authentication: Ensure that only authorized entities may consume a Web Service . Web services need to authorize web service clients the same way web applications authorize users. A web service needs to make sure a web service client is authorized to: perform a certain action (coarse-grained); on the requested data (fine-grained).A web service should authorize its clients whether they have access to the method in question. Following authentication, the web service should check the privileges of the requesting entity whether they have access to the requested resource. This should be done on every request. Ensure access to administration and management functions within the Web Service Application is limited to web service administrators. Ideally, any administrative capabilities would be in an application that is completely separate from the web services being managed by these capabilities, thus completely separating normal users from these sensitive functions.
- Non-repudiation: Prevent a web services consumer from denying having performed a particular transaction.
- Confidentiality: Ensure that SOAP messages traversing networks are not viewed or modified by attackers. WS-Security and WS-Secure Conversation provide the confidentiality services necessary. Messages containing sensitive data must be encrypted using a strong encryption cipher. This could be transport encryption or message encryption. Messages containing sensitive data that must remain encrypted at rest after receipt must be encrypted with strong data encryption, not just transport encryption.
- Message Integrity: This is for data at rest. Integrity of data in transit can easily be provided by SSL/TLS.
- Protection of resources: Ensure that individual Web services are adequately protected through appropriate identification, authentication, and access control mechanisms. There is a plethora of standards available for controlling access to Web services.
- Negotiation of contracts: To truly meet the goals of SOA and automate business processes, Web services should be capable of negotiating business contracts as well as the QoP and QoS of the associated transactions. While this remains a hard problem, standards are emerging to address portions of contract negotiation—particularly in the QoP and QoS field.
- Trust management: One of the underlying principles of security is ensuring that all entities involved in a transaction trust one another. To this end, Web services support a variety of trust models that can be used to enable Web services to trust the identities of entities within the SOA.
- Security properties: All Web service security processes, tools, and techniques rely on secure implementation. A vulnerable Web service may allow attackers to bypass many—if not all—of the security mechanisms.
- Transport Confidentiality: Transport confidentiality protects against eavesdropping and man-in-the-middle attacks against web service communications to/from the server. All communication with and between web services containing sensitive features, an authenticated session, or transfer of sensitive data must be encrypted using well-configured TLS. This is recommended even if the messages themselves are encrypted because SSL/TLS provides numerous benefits beyond traffic confidentiality including integrity protection, replay defenses, and server authentication.
- Server Authentication: SSL/TLS must be used to authenticate the service provider to the service consumer. The service consumer should verify the server certificate is issued by a trusted provider, is not expired, is not revoked, matches the domain name of the service, and that the server has proven that it has the private key associated with the public key certificate (by properly signing something or successfully decrypting something encrypted with the associated public key).
- Schema Validation: Schema validation enforces constraints and syntax defined by the schema. Web services must validate SOAP payloads against their associated XML schema definition (XSD).The XSD defined for a SOAP web service should, at a minimum, define the maximum length and character set of every parameter allowed to pass into and out of the web service. The XSD defined for a SOAP web service should define strong (ideally white list) validation patterns for all fixed format parameters (e.g., zip codes, phone numbers, list values, etc.).
- Output Encoding: Web services need to ensure that output sent to clients is encoded to be consumed as data and not as scripts. This gets pretty important when web service clients use the output to render HTML pages either directly or indirectly using AJAX objects.
Different Security Threats
- Distributed Denial of Service (DDoS) - DoS / DDoS attacks have increased in popularity. They are easy to employ and highly effective. Often, the attacker has to do little to cause your website harm. The goal is to disrupt your business by taking your website offline.
- Volume Based Attacks - Overload your web servers and application platforms resource.
- Protocol Based Attacks - The internet is all based on protocols; it's how things get from point A to point B. This type of attack can include things likes Ping of Death, SYN Flood (SYNchonize and ACKnowledge message), Packet modifications and others.
- Layer 7 application attack (HTTP Flood Attack) - is when an attacker makes use of standard GET / POST requests in an effort to overload your web servers response ability. They can generate thousands of requests a second. This attack can occur over HTTP or HTTPS and much easier to implement.
- Simple Service Discovery Protocol (SSDP Attack) - It often targets traditional SSDP ports, (1900) and destination port 7 (echo). SSDP is usually used by plug and play devices
- User Datagram Protocol (UDP Attack ) - will randomly flood various ports on your web server, also known as Layer 3 / 4 attacks. This forces the web server to respond.
- Domain Name Server Amplification (DNS Attack) – It occurs at Layer 3 / 4. They make use of publicly accessible DNS servers around the world to overwhelm your web server with DNS response traffic.
- Backdoor Injections (SQL Injection Attacks) – Injection flaws, such as SQL, OS, and LDAP injection occur when untrusted data is sent as part of a command or query. The attacker’s hostile data can execute unintended commands and pollute data.
- Cross-site Scripting(XSS)- XSS flaws occur whenever an application takes untrusted data and sends it to a web browser. XSS allows attackers to execute scripts in the victim’s browser which can hijack user sessions or redirect the user to malicious sites.
- Broken Authentication- Application functions related to authentication and session management are often not implemented correctly, allowing attackers to compromise passwords, keys, or session tokens.
How to Protect
A Web Application Firewall (WAF) is a shielding safeguard intended to protect web applications against attack. A WAF is one leg of the three-legged web security stool. The other two legs are application security testing and secure coding practices.
What is WAF?
A web application firewall (WAF) is an appliance, server plugin, or filter that applies a set of rules to an HTTP conversation. Generally, these rules cover common attacks such as cross-site scripting (XSS) and SQL injection. By customizing the rules to your application, many attacks can be identified and blocked. The effort to perform this customization can be significant and needs to be maintained as the application is modified.
WAFs are designed to protect web applications/servers from web-based attacks that Network Firewall cannot prevent. They sit in-line and monitor traffic to and from web applications/servers. WAFs interrogate the behavior and logic of what is requested and returned. WAFs protect against web application threats like SQL injection, cross-site scripting, session hijacking, parameter or URL tampering and buffer overflows. They do so by analyzing the contents of each incoming and outgoing packet.
WAFs are typically deployed in some sort of proxy fashion just in front of the web applications, so they do not see all traffic on our networks. By monitoring the traffic before it reaches the web application, WAFs can analyze requests before passing them on. This is what gives them such an advantage.
WAFs not only detect attacks that are known to occur in web application environments, they also detect (and can prevent) new unknown types of attacks. By watching for unusual or unexpected patterns in the traffic they can alert and/or defend against unknown attacks. For example- if a WAF detects that the application is returning much more data than it is expected to, the WAF can block it and send an alert.
A WAF typically follows either a positive or negative security model when it comes to developing security policies for your applications. A positive security model only allows traffic to pass which is known to be good, all other traffic is blocked. A negative security model allows all traffic and attempts to block that which is malicious. Some WAF implementations attempt to use both models, but generally, products use one or the other. A WAF using a positive security model typically requires more configurations and tuning, while a WAF with a negative security model will rely more on behavioral learning capabilities.
Input Validation: Lack of proper input validation is one of the prime culprits in security vulnerabilities. The Web Application Firewall decrypts all encrypted traffic and normalizes inputs to ensure that all data is inspected and validated against known attack patterns before sending to the backend servers.
Security Checks: Simplify operations and infrastructure by controlling and enforcing attack prevention, privacy (SSL cryptography) and AAA (Authentication, Authorization, Accounting) policy from a single control point.
Digital Signature: The Web Application Firewall appends a digital signature to any web Server cookie before delivering it to the client’s browser to authenticate subsequent requests.
Cloaking: The hackers try small operations on the website to simulate error conditions to exposes information about the web server, application server, or the database being used.
Why WAF in Trusted Domain?
- By configuring more aggressive rules in the internal WAF, we can eliminate the burden of re-authentication and recreating security patterns through the processing tree.
- Provides a central WAF rules repository.
- If the web server is under attack from the outside, it can further compromise internal machines. This is a quite common scenario we saw in incident response.
- If users are allowed at some point to upload/modify content hosted on the web server: that content has to be secured/checked. For instance, malicious content may be inserted into the web server content (like links to exploitation codes, etc.), and then be transparently/automatically accessed by any clients browsing the web server.
- Critical servers can be closely monitored when they are isolated behind an internal WAF. Any malicious activity would be much easier to detect.
- Added security to the internal machines, connected through VPN. For example, a laptop pc from the airport accessing the Internet might VPN into our Enterprise as well.
- Malicious Insider
WAF Selection Criteria:
- Protection against OWASP top ten
- Very few false positives (i.e., should NEVER disallow an authorized request)
- Strength of default (out-of-the-box) defenses
- Power and ease of learn mode
- Types of vulnerabilities it can prevent
- Detects disclosure and unauthorized content in outbound reply messages, such as credit-card and Social Security numbers
- Both positive and negative security model support
- Simplified and intuitive user interface
- Cluster mode support
- High performance (milliseconds latency)
- Complete alerting, forensics, reporting capabilities
- Web services\XML support
- Brute force protection
- Ability to active (block and log), passive (log only) and bypass the web traffic
- Ability to keep individual users constrained to exactly what they have seen in the current session
- Ability to be configured to prevent ANY specific problem (e.g., emergency patches)
- Form factor: software vs. hardware (hardware generally preferred)
Published at DZone with permission of saumik Gupta . See the original article here.
Opinions expressed by DZone contributors are their own.