Don't let these common web security threats give you a fright

This Halloween, your neighbourhood ghouls and goblins aren't the only suspects causing a fright. Threats to your web security seem like they're flying...

Tuesday October 22, 2019

This Halloween, your neighbourhood ghouls and goblins aren't the only suspects causing a fright. Threats to your web security seem like they're flying in just as often as witches in the night.

Keeping your website and digital information safe and secure is at the top of everyone's priority list. But being safe is easier said than done. Staying vigilant against security breaches and threats take significant time and resources. There are even web applications that work to consistently block threats to your data. If your website or security based applications are designed poorly, your risk level increases and you can become vulnerable to a wide range of hazards, which can cause serious damage to your web presence.

We're aware threats to your web security can raise a few hairs, but we're here to help! Our web security experts have provided your IT staff with some advanced best practices to keep your data secure and protected this trick-or-treat season.

Applications, threats and mitigation techniques

Cross site scripting (XSS)

What is it?
Cross-site scripting (XSS) attacks occur when malicious scripts (Javascript) are injected to established or trusted websites to run against site visitors. This allows an attacker to do many things, including stealing credentials, run cryptominers, run exploits against the visitor’s browser, and more.

You can manually insert keyboard characters like ‘ and “, or HTML such as <script>alert(‘xss’)</script> into everything to discover threatening instances. However, it is more practical to run a vulnerability scanner (Burp Suite Pro, ZAP, etc.) on all web traffic. This will automate and expand the amount of testing that you can do. Just be aware that these tools are not perfect, so you should always double check if there are any places where the code executes somewhere other than where it’s first inserted.

Use proper output encoding on all views handling user-submitted data. You need to do this on all parts of the site that use this data, so be careful not to miss any! You can also try to sanitize or strip out the data, but sometimes, that just can’t be done, for example when dealing with a Bob “Mr. Complicated Name” O’Connor. View tips on preventing XSS attacks.

Rich text editor fields
If your website has a Rich Text Editor field, we highly recommended using HTMLSanitizer (.NET), or a similar library to sanitize your data. The problem with Rich text editors is that they usually store data as HTML, and it’s hard to make sure the HTML doesn’t contain anything bad. You can try to write your own HTMLSanitizer, but be careful, as it can be very easy to miss something!

Structured Query Language (SQL) injection

What is it?
Input used by a structured query language (SQL) statement is not sanitized, meaning an attacker can write unwanted or harmful SQL statements into your website. This means outsiders can read your entire database and sometimes even edit it. This becomes worse when your database contains sensitive data, such as user credentials or health records.

Manual testing with ‘ and ‘ OR ‘1’=’1 can work, however given the wide variety of payloads it’s better to use an application scanner like Burp Suite Pro or ZAP, and confirm reported concerns with a more specialized tool such as sqlmap.

Mitigation: There are many options to mitigate this, but we recommend using prepared statements. Please note that there are trade-offs, and some defenses are not always effective. View a helpful SQL Injection Prevention Cheat Sheet.

File upload controls (implemented insecurely)

What is it?
Suppose your website has a file upload control, but it doesn’t restrict what you can upload, or where in the file system it can read or write to. This could mean that someone can access sensitive information stored on the file system, or even upload a webshell and take over the web server.

Try uploading some webshells. If successful, try to navigate to them and see if the server tries to execute the webshell code. If it does, that’s not a good sign. Try to upload things to various places on the file system. You can try to manually test path traversal strings (../../../../../../filename), but it’s often better to use a web application scanner to automate this testing for you.

Use a file extension white list. Black lists do not work and are difficult to implement. Ensure that you can only store files in an appropriate place in the file system. Learn more about unrestricted file uploads.

Open redirect

What is it?
This occurs when an application redirects to another location, and an attacker changes the destination to point at any random external URL. This can be used to mislead victims into thinking they are using the application, when they’re actually going somewhere else instead, and lead to credential theft by through fake login pages.

You can try manual testing; however, application scanners are very good at correctly identifying these issues.

Path variables used in GET / POST parameters should be validated to ensure that they only point to a location on the application’s own domains (if possible). View a helpful Unvalidated Redirects and Forwards Cheat Sheet.

Missing access control logic

What is it?
This occurs when lower level users can access and do things that they shouldn’t be able to do. The threat of this depends on the application. For example, can job applicants create and accept jobs?

Try to make changes that different users shouldn’t be able to make. You will need to do this at the HTTP (GET / POST, etc.) request level to be sure. Some developers have attempted to solve this problem via the user interface (UI), by trying things like hiding the controls. However, this is not sufficient. Sometimes you can replay a POST request as the “wrong” user.

Mitigation: Use proper ACL. This is a design and requirements problem, so make sure those are clear. View tips on preventing broken access control.

Cross-site request forgery – CSRF / XSRF

What is it?
It has a complicated name, but it's a simple concept. Cross-site request forgery (CSRF) occurs when you have logged into one website and then visit another site that you didn't realize was malicious. If CSRF is possible, the malicious site can make changes to the first website. For example, when attackers try to get banking information, you may see this:

Think of CSRF as a danger magnifier. Are you ignoring some vulnerability because you need “Super Admin” permissions to access it, and do you trust your Super Admins not to abuse it? What if CSRF is possible and someone tricks a Super Admin into stumbling upon the exploit?

Inspect all HTML traffic for obvious defenses (anti-CSRF tokens). If you find any, try taking them out of the HTTP requests and see if the application still works normally.

Add anti-CSRF tokens to all necessary GET/POST requests. Test and make sure they work properly. View tips on preventing CSRF.

Unpatched third-party libraries with security flaws

Libraries are great and there is no point in reinventing the wheel! However, some wheels are full of SQL and operating system (OS) Command injection faults, and are just sitting there for anyone to examine. You don’t want to make a bike out of any wheel you find just lying around.

What is it?
Unpatched third-party libraries with security flaws include any of the issues mentioned in this article and many others. Suppose you are a .NET shop and your developers work in a language that isn’t usually vulnerable to buffer overflow exploits. Guess what might happen if they try to include a third-party library? Now you're vulnerable to attackers.

Critical infrastructure (CCIRC) alerts, CVEDETAILS, and are some ways you can learn about flaws in libraries; however, this may come too late after exploits have already become public knowledge. Search for some tools and browser plugins that can warn you about known flaws. You can also perform your own security analysis and testing, but you’ll need to factor in the cost of doing so. 

All you can really do is make sure that you update/upgrade third party libraries when you become aware of flaws. This is a cost of doing business, and should be considered when including in a project. Beware of customizing third party libraries, as this makes upgrading ever more difficult. View tips on preventing unpatched third-party libraries with security flaws.


By becoming more aware of these common web security threats and responding accordingly, you are well on your way to staying safe and vanquishing those tricky Halloween (and year-round) risks!

Let's Talk
  • Services
  • Creative
  • pingstreet

© eSolutionsGroup 2020

Pin It on Pinterest

Share This