A safe and secure website should be the top priority for everyone. 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.

Discovery

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.

Mitigation

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

Discovery

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 upload a webshell and take over the web server.

Discovery

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.

Mitigation

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 somewhere else instead. This can lead to credential theft by through fake login pages.

Discovery

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

Mitigation

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?

Discovery

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 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: VulnerableBank.com/transfer?account=badguyAcctNumber&value=1000

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?

Discovery

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.

Mitigation

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.

Discovery

Critical infrastructure (CCIRC) alerts, CVEDETAILS, and exploit-db.com are ways you can learn about flaws in libraries. However, this may come too late after exploits have already become public knowledge. Search for 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. 

Mitigation

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 it 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!