Despite the sophistication of web technologies, many web applications have experienced a data breach over the years putting millions of consumers’ sensitive data information in the hands of criminals.

If a web site’s server and applications are not protected from security vulnerabilities, identities, credit card information, and billions of dollars are at risk. Unfortunately, firewalls do not provide enough protection.

Firewalls, IDS, IPS are not enough.

Attackers are aware of the valuable information accessible through Web applications, and their attempts to get at it are often unwittingly assisted by several important factors. Conscientious organizations carefully protect their perimeters with intrusion detection systems and firewalls, but these firewalls must keep ports 80 and 443 (SSL) open to conduct online business. These ports represent open doors to attackers, who have figured out thousands of ways to penetrate Web applications.

Extreme Vulnerabilities

Historically, security breaches occurred at the network layer of the corporate systems. Today, hackers are manipulating web applications inside the corporate firewall. This entry enables them to access sensitive corporate and customer data. The standard security measures for protecting network traffic do not defend against web application level attacks.

OWASP Top 10 Web Application Security Vulnerabilities

Open Web Application Security Project (OWASP), an organization that focuses on improving the security of application software, has put together a list of the top 10 web application security vulnerabilities.

1. Cross Site Scripting (XSS)
2. Injection Flaws
3. Broken Authentication and Session Management
4. Insecure Direct Object Reference
5. Cross-Site Request Forgery (CSRF)
6. Security Misconfiguration
7. Insecure Cryptographic Storage
8. Failure to Restrict URL Access
9. Insufficient Transport Layer Protection
10. Unvalidated Redirects and Forwards

Cross Site Scripting XSS

xss-img01.jpeg

XSS stands for Cross Site Scripting. XSS is a hacking technique for a web application. It allows the user to perform a pharming attack. It is a term that has been given to the web pages that will enable the user to supply some data capable of altering the page for the viewer. The code is vulnerable to XSS where ever it uses input parameter in the output HTML stream returned to the client.

Another word for this particular type of Internet threat is script injection which works by manipulating the JavaScript code in a specific site’s URL. As a user clicks on that URL, this script takes over with the use of a forged website address and then it begins to work by letting the hacker manipulate the target site. There are several countermeasures which you can do to fight off this attack:

Countermeasures:

  • Implement input validation
  • Utilization of a protected language. All applications should be written under this language. Look for highly rated programming software to ensure that you are indeed using a protected app.

Recommended Tool:
The recommended tool for minimizing the risk of XSS (Cross Site Scripting) is ZAP.

Injection Flaws

Injections are attacks which include SQL injection, LDAP injection, and CRLF injection. These type of attacks works by sending untrusted data to be interpreted by the target without proper authorization. Most notable is the SQL injection which is a code injection technique in which a piece of malicious SQL code is injected in a web form, to exploit a security vulnerability occurring in the database layer of an application.

There are several ways to fight an SQL injection attack. One way is to refrain from accessing the database as its principal owner or as a superuser. It’s better to use databases which can be customized according to users. This kind of database limits the type of access a user is granted with. There is also a limit regarding the task that can be accomplished. Input validation is also significant in preventing and mitigating these type of injection attacks.

Countermeasure(s):
Implement input validation

Recommended Tool:
SQL Inject Me is an efficient tool that can help to identify injection risks.
URL: https://addons.mozilla.org/en-GB/firefox/addon/sql-inject-me/

Broken Authentication & Session Management

Broken authentication is a standard security risk that can result in identity theft. If the web application functions that deal with user authentication and session management are not appropriately implemented, valuable user data including their passwords and credit card information can be sent to an attacker.

Countermeasure(s):

  • Session Management
  • Protect Credentials: If user authentication credentials are stored using hashing or encryption, should be protected.
  • Never expose session ID in the website address: Sessions IDs should not be revealed in the URL (example, URL rewriting).
  • Sessions IDs should timeout: There should be proper invalidation of user sessions or authentication during logout.
  • Recreate sessions IDs: Session IDs should be recreated after successful login.
  • Do not send credentials over unencrypted connections: Passwords, session IDs, and other credentials should not be carried over unencrypted connections.

Broken Authentication

  • Password length: Password length should be minimum eight characters long, to make it as complex as possible. This will make it difficult to guess using a brute force attack.
  • Password complexity: Passwords should be a combination of alphanumeric characters, consisting of upper and lower case letters, numbers, symbols, etc.
  • Username/Password enumeration: Authentication failure responses should not give any clues as to which part of the authentication data was incorrect. Example, rather than displaying “Invalid username” or “invalid password,” you should instead use “invalid username and password” for both.
  • Brute force login protection: Enforce account disabling after a set number of invalid login attempts (example, five attempts is usually the universal standard). The offending account must be disabled for a period long enough to mitigate brute force guessing of the login credentials.

Recommended Tool:
Hackbar is one tool that can help deal effectively with broken authentication security risk.

URL: https://chrome.google.com/webstore/detail/hackbar/ejljggkpbkchhfcplgpaegmbfhenekdc?hl=en

Insecure Direct Object Reference

These can happen if an object is under the exposure of a weak reference. If security measures are not implemented, hackers can easily control the text to get their hands on data.

Countermeasures:
Burp Suite can be used to test web applications for insecure direct object references.

URL: https://portswigger.net/burp

Cross-Site Request Forgery (CSRF)

As the name suggests, Cross-Site Request Forgery (CSRF) is an attack that forces an end user to execute unwanted actions on a web application in which they’re currently authenticated. CSRF attacks specifically target state-changing requests, not theft of data since the attacker has no way of seeing the response to the forged request. With a little help of social engineering (such as sending a link via email or chat), an attacker may trick the users of a web application into executing actions of the attacker’s choosing. If the victim is a regular user, a successful CSRF attack can force the user to perform state-changing requests like transferring funds, changing their email address, and so forth. If the victim is an administrative account, CSRF can compromise the entire web application.

Recommended CSRF Defense
Once you have verified that the request appears to be the same origin request so far, we recommend the second check as an additional precaution to make sure. This second check can involve custom defense mechanisms using CSRF specific tokens created and verified by your application or can rely on the presence of other HTTP headers depending on the level of rigor/security you want.

There are numerous ways you can specifically defend against CSRF. We recommend using one of the following (in conjunction to the check recommended above):

  • Synchronizer (i.e., CSRF) Tokens (requires session state)The following approaches do not require server-side state:
  • Double Cookie Défense
  • Encrypted Token Pattern
  • Custom Header – e.g., X-Requested-With: XMLHttpRequest

These are listed in order of strength of the defense, So, I advise you use the strongest defense that makes sense in your application situation.

Recommended Tools for CSRF:
The tool used to modify “HTTP/HTTPS” headers and POST parameters are called Tamper Data. This device has recently run into some compatibility issues with Google accelerator.

URL: https://addons.mozilla.org/en-GB/firefox/addon/tamper-data/

Security Misconfiguration

configuration-img01.jpeg

Security misconfiguration occurs when the code libraries being used by the application are not up to date, and secure configurations for all frameworks, platforms, and servers are not defined.

Countermeasures for Security Misconfiguration
All environments such as development, QA, and production environments should be configured identically using different passwords used in each context that cannot be hacked easily.

  • Adopt a robust application architecture that provides practical and secure separation between components.
  • Routinely run automated scans and perform periodic audits of all environments.

Recommended Tools for Security Misconfiguration

To test for any security misconfiguration, MBSA (Microsoft Baseline Security Analyzer) is highly recommended.

Insecure Cryptographic Storage

cryptographic-key-management-img01.jpeg

Sensitive data such as credit card information, login credentials, and other similar data entries should be protected by using proper encryption. If such data is poorly preserved, attackers can quickly have access to it.

Developers must ensure that the correct data is being encrypted, must avoid known bad algorithms, and must ensure that the key storage is adequate.

Furthermore, the developers must be able to identify sensitive data and take steps to move this data from memory as soon as it is not required.

Prevention Measures for Insecure Cryptographic Storage
There are several approaches to encrypting sensitive data at rest, one or more of which must be implemented to mitigate Insecure Cryptographic Storage:

  • Database Encryption: Most modern database platforms offer the ability to partially (i.e., a selected number of columns) or entirely (by tablespace) encrypt database storage. This is configured by the database administrator and is transparent to applications using the database. Note however that this approach only protects against theft of the database, as the data is fully accessible via a compromised account or certificate.
  • Application Encryption: The application is responsible for encrypting data before storing it and decrypting after reading it. Because all other applications seeking to share the date must implement the same solution, this presents a security challenge. The data is protected from database theft and database account compromise, but not application compromise. It is essential that the application employs a modern public encryption algorithm that is not known to have been previously compromised.

Avoid storing the data. It is highly advisable not to persist in sensitive data, unless necessary for business reasons.

Failure to Restrict URL Access

Most web applications check for URL security access when protected pages are being accessed, but do not perform these checks each time. As a result, attackers can easily forge URLs and access sensitive data and hidden pages.

Recommended Tool(s):
Veracode’s static code analysis tool is an excellent solution to find URL access vulnerabilities in your application code.

Insufficient Transport Layer Protection

security-features-for-networks-img01.jpeg

Through transport layer protection, web applications can assure the users that their interaction with the website is happening in a secure environment and their data is safe from attackers. When there is insufficient TLS (Transport Layer Security), the user can be prompted with a warning about the low protection. Without transport layer protection user confidentiality and sensitive data are at risk. Implementing SSL (Secure Socket Layer) is currently the most common way to provide this protection, and the SSL implementation needs to be checked to ensure that it is correctly implemented.

Prevention Measure(s): Use TLS/SSL.

Recommended Tool(s):
Calomel SSL Validation is a helpful add-on in this regard.

Unvalidated Redirects and Forwards

Web applications sometimes direct users to different pages and links without any validation. These invalidated redirects can result in the user landing on malicious pages and websites. By modifying untrusted URL input to a malicious site, an attacker may successfully launch a phishing scam and steal user credentials. Because the server name in the changed link is identical to the original site, phishing attempts may have a more trustworthy appearance. Unvalidated redirect and forward attacks can also be used to maliciously craft a URL that would pass the application’s access control check and then forward the attacker to privileged functions that they would typically not be able to access.

Recommended Tool(s):
Veracode’s static code analysis tool or Codeplex’s Watcher can be used to find and eradicate this security risk in your coding.

Conclusion

With over 1.5 billion websites on the World Wide Web today, it’s no news that many are vulnerable to web application attacks. Fragile sites are wide open to attack and easy victims when targeted. Intruders need only to exploit a single vulnerability.
Web application vulnerability assessment is one surefire way to mitigate these form of attacks.

A web application scanner, which protects applications and servers from hackers, must provide an automated internet security service that searches for software vulnerabilities within web applications.

A web application scan should crawl the entire website, analyze in-depth each & every file, and display the whole website structure. The scanner has to perform an automatic audit for common network security vulnerabilities while launching a series of simulated web attacks.

A web application vulnerability Assessment should execute continuous dynamic tests combined with simulation web-application attacks during the scanning process.
The web application scanner must have a continually updated service database. A website security test should identify the security vulnerabilities and recommend the optimally matched solution.

The vulnerability check has to deliver an executive summary report to management and a detailed description to the technical teams with the severity levels of each vulnerability.

It is recommended that the detailed report include an in-depth technical explanation of each vulnerability as well as appropriate recommendations. The website security test will conduct subsequent vulnerability scans and generate trend analysis reports that allow the customer to compare tests and track progress.

In conclusion, no web application can ever indeed be 100% secure, but with consistent security assessment and analysis, applications can be improved to protect the users from most attackers.

Do you find this guide useful?  Please make sure to let me know if you have any comments in the comments box below! If you are a business in need of a secure development strategy and policy, please feel free to contact me at support@dangata.com or call me directly on 07540 460322.

 

Posted by Dan K Jatau Sr. MSc, PhD, MBCS, MInstLM

Dan K Jatau is a Nottingham, UK-based Information security and technology infrastructure expert and researcher who likes to write about technology subjects from both a business and technical perspective. His current interests are business-driven security architectures, identity and access, the Cloud, virtualization security and all aspects of security. He currently works in security program development and architecture and develops enterprise security programs for SMEs.