BLOG
CATEGORIES
web-application-vulnerabilities BLOG

Web Application Vulnerabilities: How to Cope

#mobile app development

When developing a new web application, it’s important to stay up-to-date on the latest security trends. The recent Equifax leakage of users’ sensitive data, including addresses, birth dates, and social security numbers, vividly demonstrates the importance of web application security.

Security is a complicated topic. The online world is constantly changing and evolving with tremendous speed. And the level of sophistication when it comes to cyber criminals and their tactics is certainly increasing. The best advice when it comes to application security is this: “If you have the least little doubt about it, there’s a problem.” Even the most up-to-date web application security systems can be hacked.

Web app vulnerabilities are carefully studied by attackers. More than 90% of attacks occur due to standard errors in the validation of incoming data, discovered vulnerabilities in the installed software components of third-party vendors, or because system administrators continue to use default settings and passwords.

In this regard, OWASP (Open Web Application Security Project) provides a classification of web application attacks and vulnerabilities including Threat Agents, Attack Vectors, Security Weakness, Technical and Business Impacts.

osap-security-risks 2017

More detailed information on the TOP 10 web application vulnerabilities can be found here.

Injections

Injections happen when an app sends untrusted data. Injection involves not only SQL, which is easily avoided in most languages, but also many other types of code, most often in interpreted languages (OS commands, NoSQL and Xpath queries, expression languages, etc.). That’s why injections are on top of the most common vulnerabilities.

How to prevent injection:

  1. Use a safe interface provided by your programming language.
  2. Pay careful attention to special characters.
  3. Use “whitelist” input validation.

Broken Authentication and Session Management

Attackers use flaws in the authentication or session management functions (e.g., exposed accounts, passwords, session IDs) to temporarily or permanently impersonate users.

Developers frequently build custom authentication and session management schemes, but building these correctly is difficult. As a result, these custom schemes frequently have a lot of flaws and finding them can be hard, as each implementation is unique.

Flaws occur in areas such as log out, change and forgot password, create & update account.

They occur when:

  • User credentials aren’t properly protected when stored (use cryptographic hash algorithms for storing credentials.)
  • Username enumeration (as a rule, an app blocks the account after several unsuccessful attempts to enter passwords, but if attackers succeeds in obtaining a sufficiently large list of valid user names, they will be able to try to enter one password for all users in turn.)
  • Weak passwords or credentials are sent over unencrypted connections. (This applies to cookies with ID session.)
  • Session IDs aren’t properly generated, invalidated and used (session fixation attack, predictable session id, etc.) 

XSS (Cross-site scripting)

XSS flaws occur when an application updates a web page with attacker controlled data without properly escaping that content or using a safe JavaScript API. Attackers can execute scripts in a victim’s browser to hijack user sessions, deface web sites, insert hostile content, redirect users, hijack the user’s browser using malware, etc. This vulnerability is difficult to prevent, especially if you allow user created messages with some html formatting. Here is an XSS example:

xss example

How to prevent XSS

More information can be found in Prevention Rules From OWASP but here is what you can do in short:

  • Validate input.
  • Validate output.
  • Eliminate dangerous insertion point. 
  • Use HTTP Security Headers.

Request forgery

CSRF (Cross-Site Request Forgery) is a type of attack that uses identity and privileges of the victim to perform an action, like transferring money to the attacker's account on behalf of victim. This occurs for some types of requests because a browser automatically includes credentials associated with the site on which user is authenticated. These requests can be made even from other domains.

Request-forgery example

CSRF mitigations:

  • Attach anti-CSRF tokens
  • Use Same-Site Cookies (not supported in all browsers)
  • Require user interaction before important actions (reauthentication, one-time token, captcha)
  • Check the “Origin” and “Referer” headers
  • Use cookie for anonymous users (to prevent Login CSRF)
  • Add additional non-standard headers, for example, X-Requested-With.

Note that not all of these measures can ensure 100% protection from CSRF attacks.

Integrated Testing Suites

Integrated testing suites help engineers manually and automatically test their web applications for vulnerabilities. Among some of widely used and trusted are Burp Suite, WebScarab, and ZAP (Zed Attack Proxy).

Web application security rules

As we stated at the beginning of the article, “if you have the least little doubt about it, there’s a problem.” This is the #1 rule of security that you should always bear in mind. Other best practices include:

  • Provide the minimum access for each part of application (principle of least privilege).
  • Do not reinvent the wheel. Use existing technologies.
  • Don’t use http, even for pages without secure information.
  • Remember that several weak vulnerabilities may eventually turn out to be serious security threats.
  • Use code analyzers and code review.
  • Provide minimum information about the technologies used.

This is really just the top of the web application vulnerabilities iceberg. Feel free to get in touch with us if you’re looking for secure web applications.

Let's get rolling!
Get a chance to build the next big thing with our development team
What can we
build for you?
Just share your idea. We make sure
every software goes to market on time.