Web Application Security
What is web application security
Web application security is the process of protecting websites and online services against different security threats that exploit vulnerabilities in an application’s code. Common targets for web application attacks are content management systems (e.g., WordPress), database administration tools (e.g., phpMyAdmin) and SaaS applications.
Perpetrators consider web applications high-priority targets due to:
The inherent complexity of their source code, which increases the likelihood of unattended vulnerabilities and malicious code manipulation.
High value rewards, including sensitive private data collected from successful source code manipulation.
Ease of execution, as most attacks can be easily automated and launched indiscriminately against thousands, or even tens or hundreds of thousands of targets at a time.
Organizations failing to secure their web applications run the risk of being attacked. Among other consequences, this can result in information theft, damaged client relationships, revoked licenses and legal proceedings.
Web application vulnerabilities
Web application vulnerabilities are typically the result of a lack of input/output sanitization, which are often exploited to either manipulate source code or gain unauthorized access.
Such vulnerabilities enable the use of different attack vectors, including:
SQL Injection – Occurs when a perpetrator uses malicious SQL code to manipulate a backend database so it reveals information. Consequences include the unauthorized viewing of lists, deletion of tables and unauthorized administrative access.
Cross-site Scripting (XSS) – XSS is an injection attack targeting users in order to access accounts, activate Trojans or modify page content. Stored XSS occurs when malicious code is injected directly into an application. Reflected XSS takes place when malicious script is reflected off of an application onto a user’s browser.
Remote File Inclusion – A hacker uses this type of attack to remotely inject a file onto a web application server. This can result in the execution of malicious scripts or code within the application, as well as data theft or manipulation.
Cross-site Request Forgery (CSRF) – An attack that could result in an unsolicited transfer of funds, changed passwords or data theft. It’s caused when a malicious web application makes a user’s browser perform an unwanted action in a site to which a user is logged on.
In theory, thorough input/output sanitization could eliminate all vulnerabilities, making an application immune to unlawful manipulation.
However, complete sanitization usually isn’t a practical option, since most applications exist in a constant development state. Moreover, applications are also frequently integrated with each other to create an increasingly complex coded environment.
Web application security solutions and enforced security procedures, such as PCI Data Security Standard (PCI DSS) certification, should be deployed to avoid such threats.
Web application firewall (WAF)
Web application firewalls (WAFs) are hardware and software solutions used for protection from application security threats. These solutions are designed to examine incoming traffic to block attack attempts, thereby compensating for any code sanitization deficiencies.
By securing data from theft and manipulation, WAF deployment meets a key criteria for PCI DSS certification. Requirement 6.6 states that all credit and debit cardholder data held in a database must be protected.
Generally, deploying a WAF doesn’t require making any changes to an application, as it is placed ahead of its DMZ at the edge of a network. From there, it acts as a gateway for all incoming traffic, blocking malicious requests before they have a chance to interact with an application.
WAFs use several different heuristics to determine which traffic is given access to an application and which needs to be weeded out. A constantly-updated signature pool enables them to instantly identify bad actors and known attack vectors.
Almost all WAFs can be custom-configured for specific use cases and security policies, and to combat emerging (a.k.a., zero-day) threats. Finally, most modern solutions leverage reputational and behavior data to gain additional insights into incoming traffic.
WAFs are typically integrated with other security solutions to form a security perimeter. These may include distributed denial of service (DDoS) protection services that provide additional scalability required to block high-volume attacks.
Web application security checklist
In addition to WAFs, there are a number of methods for securing web applications. The following processes should be part of any web application security checklist:
Information gathering – Manually review the application, identifying entry points and client-side codes. Classify third-party hosted content.
Authorization – Test the application for path traversals; vertical and horizontal access control issues; missing authorization and insecure, direct object references.
Cryptography – Secure all data transmissions. Has specific data been encrypted? Have weak algorithms been used? Do randomness errors exist?
Denial of service – Improve an application’s resilience against denial of service threats by testing for anti-automation, account lockout, HTTP protocol DoS and SQL wildcard DoS. This doesn’t cover protection from high-volume DoS and DDoS attacks, which are best countered by a combination of filtering solutions and scalable resources.
Refer to the OWASP Web Application Security Testing Cheat Sheet for additional information; it’s also a valuable resource for other security-related matters.
Detect Web Application Attacks Using Web Server Access Logs
Why Web Server Access Logs are Important?
In any security scenario – even though we try to ensure that we do as best as we can to protect the systems — we need to consider the possibility that we could do better. We need to learn from day-to-day traffic, from ways by which hackers attack our system, and use that to improve our WAF rules.
Secondly, even the best security could be breached. And this could be due to various reasons including the discovery of zero-day vulnerabilities in the platforms used. And in case of a breach or a successful WAF evasion, the only way we would get information about the hack or the hacker would be through web server access logs.
What can we learn from web server logs?
To elaborate further, usually, before a hacker is successfully able to breach the website, he/she would probably have made a few unsuccessful attempts. These attempts if not blocked by WAF would be available as unusual entries in the web server logs.
Also, in the normal operation of the web apps, regular users would be using certain URLs, making a certain type of requests, etc. This normal behavior would result in certain log entries in the web server access logs. Security admins operating the website should be intimately familiar with normal web server logs corresponding to the normal use of their web apps. Thus, when unusual entries arise in the web server access logs, they represent anomalies.
Some of them could be attempts to hack. Thus, security admins should write scripts or use automated tools to analyze web server logs. These scripts would filter out the normal entries and only throw out unusual entries which can then be looked at by a human. The source IP addresses corresponding to these unusual entries can be watched or subsequently blocked, as also more signatures can be added into the WAF corresponding to these attack attempts by understanding what these hackers are trying to do.
Here are a few scenarios that could happen
A URL that contains the word admin could be an attempt to gain admin access or access using admin privileges.
An attempt that has a name of a CMS (content management system) platform that is not supported by the website – say Joomla where the website is not running on Joomla – reflects an attempt by a bot to figure out the type of platform used by the site. Normal users who use a browser wouldn’t be able to come up with such a URL in the normal course of their use.
A zero-day vulnerability found in the wild could result in an unusual URL. A WAF wouldn’t have a signature for such a vulnerability until the vulnerability becomes well-known.
Last updated
