5-best-practices-web-app-security

5 Best Practices for Web Application Security

When it comes to web application security, there are many measures you can implement to reduce the chances of an intruder stealing sensitive data, injecting malware into a webpage, or public defacement. As more and more organizations transition their business operations to web applications, security in the development process can no longer be an afterthought. Whether it’s a code injection, privilege escalation, DDoS attack, or a vulnerable element, bad actors are constantly looking for creative ways to manipulate exploits for personal gain.

We’ve rounded up our top five (5) best practices to help you fortify your application security.

Never, ever trust user input

Input validation is a critical layer of web application security, acting as the first line of defense. Malicious actors will often times attempt to submit malicious inputs through any and all available entry points. Sanitizing this input against well thought-out requirements and restrictions is a critical first step. Take a “last name” field for example; limiting character usage (hyphens, single quotes, ASCII vs unicode, etc) and character length is a strong first step.

01-edb
(SQL Injection results found on exploit-db.com.com, an Offensive Security funded project)

02-edb
(XML External Entity entries found on from exploit-db.com.com, an Offensive Security funded project)

If the entered  data fails to meet the proper requirements, the server should reject the request. This is an example of white listing input validation, as only approved and well-formed data  are processed by the server. On the other hand, black listing input validation only excludes specific data inputs to prevent specific attacks. Generally, whitelisting is a more effective input validation strategy, as it prevents numerous (and often unforeseen) types of attacks.

Disable unused functionality and don’t save data you don’t use

As a general rule of thumb, if a functionality or daemon is not utilized by your web application, disable it. Maybe it’s an unused SMTP feature, plugin, unused subdomain, or a theme. If your web application doesn’t utilize it, disable it. Leaving unused functionality available only leaves additional code that increases the attack surface of an application.

03-edb
(Various CMS Plugin attacks found on exploit-db.com.com, an Offensive Security funded project)

Additionally, don’t collect data you don’t intend on using. Far too many companies collect data they don’t need and it can come back to bite them. You can’t leak what you don’t have.

Conduct Regular Security Assessments

Contracting an outside firm to routinely review your application’s security measures is wise. An independent set of eyes, someone who is unfamiliar with your infrastructure and systems, will think differently and test vulnerabilities you might have glossed over.

Web application security audits are typically conducted quarterly, especially if the application is handling any level of sensitive data (which they often are).

If you’re interested in what an in-depth security assessment looks like, take a look here to see an example penetration testing report that the Offensive Security team conducts for select clients.

Invest in ongoing cybersecurity training

Investing in on-going cybersecurity training for your team is likely one of the most valuable actions you can take to protect your web application’s security. Anyone who works on the application front whether it be security analysts, software engineers, or web designers should receive training and education. They need to understand how attacks can manipulate the code they write.  Web applications are handling increasing amounts of sensitive personal and business data; and as a result, security needs to be top of mind for every employee working near the application.

AWAE, or Advanced Web Attacks and Exploitation, is the industry’s premier web application security and pentesting training. Upon successful completion of the course and exam, students receive the OSWE (Offensive Security Web Expert) certification. The course is designed for advanced pen-testers, software engineers, web developers, and generally anyone who works near a web application.

Many team leads will send their people to complete the AWAE course and receive their OSWE certification, as it’s a phenomenal way to develop and retain in-house cybersecurity talent (which is notoriously difficult). OSWE is a certification provided Offensive Security, the same makers of OSCP, the infamous penetration testing certification. It’s an affordable course offering an invaluable education into the protection of your web application. With the rapidly changing nature of the InfoSec space, it’s critical that your team receives up-to-date training on the latest attacks and exploitation techniques.

Create a Bug Bounty Program

A public bug bounty program can go a long way in proactively identifying and patching application vulnerabilities. By offering monetary or other rewards to researchers who privately disclose application vulnerabilities, your team can be ahead of the curve in preventing potential attacks.

It will require management buy-in and dedicated resource allocation, but it’s well worth the pay off if a researcher comes forward with a application-breaking bug that has the potential to expose sensitive personal data or jeopardize business assets. GDPR, the landmark data privacy law recently enacted in the EU, enforces data breach fines up to 20 million euros or 4% of global revenue, whichever is higher. There’s also a clear PR benefit: a bug bounty program reduces the chance of your company’s name being on the front page of CNN in a massive hack. No one wants to be the subject of a new big attack.

Make sure to implement a strong, clear policy for researchers:

  • Defining compensation tiers
  • Prioritizing the research of specific vulnerabilities
  • Scope of research work
  • Specific non-disclosure terms

A bug bounty program is most worthwhile when a mature security program already exists. It’s critical to establish a clear internal resolution process, to ensure that patches are made quickly and thoroughly.

Here at Offensive Security, we operate our own full service bug bounty program. Take a look to see how we do it.


New call-to-action

Free Download: Web Application Security guide