Web Application Security Assessment

Secure web apps

 

 

Overview

90 percent of the web applications subject to their assessments contained common vulnerabilities that put in jeopardy the servers on which they ran or left subject to corruption the data the application handles. This puts the organization at risk of data loss, leakage and corruption. The company’s reputation is at risk and may result in millions in losses due to data loss, loss of confidence from the public and litigation expenses.

Vulnerabilities We Address

1. Un-validated Input

This is a design problem and rests squarely on the shoulders of the web developers and programmers. No number of firewalls, intrusion detection systems, or even up to-date patches for the web server can avert risks brought by invalidated data being received by the web-based program.

With our help we help identify this risks and guide programmers on data validation best practices.

Parameter Tampering

This is a subset of input validation errors. In parameter tampering, though, there is more effort required on the part of the attacker other than just putting unexpected data in an input box.

By modifying variables that use hidden tags in form variables an attacker can easily submit modified input or even hijack someone’s session.

2. Cross-Site Request Forgery (CSRF)

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.

Cookie Poisoning

A simplistic example of cookie poisoning might be a parallel to the parameter tampering vulnerability. If a programmer passes data from one step in a process to another via HTTP cookies, the data in the cookie may be edited before it is retrieved by the server, giving the program the hacker’s data instead of what was intended.

3.  Cross-Site Scripting (XSS)

XSS flaws occur whenever an application takes untrusted data and sends it to a web browser without proper validation or 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.

4. 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 data without proper authorization.

5.  Improper Error Handling

In the SQL injection example above, the attack was made easier by the hacker being able to determine table structure from error messages. The more information an attacker has, the easier the web site is to hack. How often do you still see sites that do homebrew user authentication that have error messages that tell which parameter, user ID or password, was not accepted. Too much information! Ideally, from a security perspective, for any error that occurs, the connection should be terminated without an error message. Too little information though, and a help desk has to answer too many calls without enough information to help the user. Keep in mind, though, that more information than is necessary gives the nefarious user a road map of your infrastructure or data structures.

6.  Insecure Storage

Just as in the case where a programmer tries to invent their own user authentication package, any attempt from a programmer to invent their own encryption algorithm is not time well spent. There are innumerable experts in cryptography that have spent their life devising encryption schemes that are uncrackable (in a time frame where the data would still be useful). There are available API packages that implement these schemes. That a programmer would use his dog’s name as a hash key (this one was for real in my past) so that he had an easy symmetric encryption algorithm to store data in a cookie is just asking for a hack.

7.  Denial of Service (DoS)

This is an extremely big category of computer attack. It encompasses any number of methods that keep a computing component from doing the job for which it is intended. Attackers can do this by flooding the device with data faster than it can be serviced, flooding a network segment with so much data that legitimate packets never get through, or exploiting a software flaw that will make a server or other device crash.

8.  Broken Authentication and Session Management

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

9.  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.

10.   Security Misconfiguration

Good security requires having a secure configuration defined and deployed for the application, frameworks, application server, web server, database server, and platform. Secure settings should be defined, implemented, and maintained, as defaults are often insecure. Additionally, software should be kept up to date.

SSL/ TSL vulnerabilities such as poodle, heartbleed, bash, Beast and Shellshock are but a few of the vulnerabilities that can be prevented through proper server configuration and use of the latest security patches.

11.  Sensitive Data Exposure

Many web applications do not properly protect sensitive data, such as credit cards, tax IDs, and authentication credentials. Attackers may steal or modify such weakly protected data to conduct credit card fraud, identity theft, or other crimes. Sensitive data deserves extra protection such as encryption at rest or in transit, as well as special precautions when exchanged with the browser.

12.  Using Components with Known Vulnerabilities

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

13.  Invalidated 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.

14.  Missing Function Level Access Control

Most web applications verify function level access rights before making that functionality visible in the UI. However, applications need to perform the same access control checks on the server when each function is accessed. If requests are not verified, attackers will be able to forge requests in order to access functionality without proper authorization.

Benefits

With this assessment in place we will help your organization understand its security posture and aid in defining and integrating security implementation and verification activities into existing development and operational processes.

The activities include threat

  • Modeling
  • Secure Design & Review
  • Secure Coding & Code Review
  • Penetration Testing
  • Remediation.

Value Add

In addition to the above common vulnerabilities our engineers make use of the OWASP cheat sheets to achieve conclusive analysis of your web application and server security posture

Related Services

Based on your interest in Red Team Testing, you might also be interested in:

  • Penetration Testing
  • Red Team assessment
  • Other Targeted Threat Services

Secure Your Web App Now

Call + 254 776 269 122 / +254 791 801 799