Ignorer kommandoer på båndet
Gå til hovedindhold

Secure web applications: 3 common mistakes that are easy to fix



By 
Ann Fonseca Jørgensen, Junior Consultant at NNIT

Working with application security can be exciting, but it has a tendency to make you paranoid. Once you are able to recognize security flaws, you tend to spot them everywhere. Since we’re using web applications more and more in our daily lives, we’re paranoid both at work and in private – tough life!

Cybercriminals are also using web applications increasingly, though not as intended. They are looking for the weakest link. Unfortunately application security is often an afterthought. In fact, many of the web applications we interact with on a daily basis contain very basic mistakes. On the plus side, many security improvements are easy to implement.

Here are three of the most common mistakes we encounter regularly:


 

Common mistake #1: Loading login forms over HTTP

A surprisingly frequent issue on web applications is to load login forms over HTTP. Some notable examples of this practice used to include the likes of Facebook and Gmail. These have now adopted much better practices, but we still see it much too often.

Loading login forms over HTTP effectively allows anyone who is monitoring the network to catch a user’s login information. With such information an attacker can effectively impersonate the user and gain access to all their information on that website. This is the case even if the login form is only loaded over HTTP, and the actual login credentials are then sent over secure HTTPS to the server. An attacker can then still tamper the insecure HTTP form or inject code into the site, e.g. a JavaScript keylogger that captures the information the user is typing into the form. It is also worth noting that a page loaded over HTTPS may be insecure if even one resource, e.g. an image, is loaded over HTTP. 


 

Image: Website loaded over HTTP in Chrome is marked as Not secure. ¨


 

Common mistake #2: Trusting user data

Users often provide input to an application, e.g. in search fields, registration forms or comment fields. This type of data should never be trusted by the application! Unfortunately, we often see that little thought has been given to this. Which characters should users be allowed to submit – are special characters such as <> actually needed, or can you make a whitelist of allowed characters? If you are showing the user’s input somewhere in the application, is the output encoded – e.g. by displaying special characters in HTML encoding? By ignoring input sanitization and output encoding, you are making the application vulnerable to Cross-site Scripting (XSS) attacks, where the attacker can inject their own code. This can persist to your database if you save user input, potentially modifying, disclosing or destroying your data.


 


 

Image: Missing input sanitization and output encoding allows this comment to appear in italics when submitted, indicating an XSS vulnerability.


 

Common mistake #3: Disclosing information

Attacks can be targeted or random. In both cases, attackers look for vulnerabilities to exploit. If you disclose your frameworks, server versions, programming error messages, etc., you are making this very easy for the attackers.

Search engines such as Shodan allow users (and attackers) to search for applications based on e.g. a specific framework version. This is possible because many applications leak this information in e.g. HTTP response headers. If an attacker creates a malware targeted at a specific framework version with known vulnerabilities, all she needs to do is search and deploy. Always consider the information you are disclosing. Is the information presence necessary for application functionality, or are you just making life easier for attackers? Can you remove the information? In any case, always make sure your systems are fully updated and patched to minimize this risk.


 

Image: Version disclosure in HTTP response headers.


 

These are just our own top three. Do you agree with the priorities, or do you see other mistakes pop up more often? Let us know in the comments.

 

About NNIT Security Insights

NNIT Security Insights is a regular column where prominent NNIT IT security advisors share their thoughts on current and future IT security challenges and how to deal with them.

NNIT has its own Computer Emergency Response Team (CERT). If lightning strikes, we have the necessary competencies in-house to respond and assist. We have also developed a range of services that can help businesses to achieve the right level of security protection to protect the business from financial and reputational damage. 

You are welcome to contact us at itmanagement@nnit.com if you want to know more about how NNIT can help your business increase its information security level.


About the author s

Ann Fonseca Jørgensen is a Security graduate in the NNIT graduate programme. She is specialised in Application Security and Identity & Access Management, with experience in GDPR and ISO27001. Customers range from large public organizations to enterprise projects. On the nerdy side she enjoys talking about securing medical & IoT devices, lock picking and data privacy.


 

Klára Hanušová is a Security graduate in the NNIT graduate programme. She is specialised in Application Security, Infrastructure Security and GDPR compliance, with experience from large projects in both the public and private sector. Outside of work she is always open to discuss data privacy issues related to web applications as well as IoT device security.