Skip to content
  • Why Deepwatch?
    • Squad Delivery Model
    • Deepwatch SecOps Platform
    • Deepwatch Secure Score
    • Deepwatch Labs
  • Solutions
    • Managed Detection and Response (MDR)
      • MDR Enterprise
      • MDR Essentials
    • Managed Extended Detection Response (MXDR)
    • Endpoint Detection and Response (EDR)
    • Vulnerability Management (VM)
    • Firewall Management Solution
  • Company
    • About
    • Leadership
    • Careers
    • Contact
  • Partners
    • Channel Partners
    • Technology Alliance Partners
  • Resources
    • Resource Library
    • Blog
    • Case Studies
    • eBooks
    • Whitepapers
    • Datasheets
    • Video
    • Newsroom
    • Events
  • Search
  • Ready to Talk?
04.08.21

Thought Leadership

Top 10 Risks for Web Application Security: #1 Injection

By Peter Halpern, 

The Open Web Application Security Project (OWASP) outlines a list of the ten most seen attacks against web applications every three years. The most recent update was in 2020.

Why is OWASP focused on ranking threats to web application security? Because in 2019 alone, 46% of reported breaches involved a web application. Web apps tend to be vulnerable, and are often released before being tested by the security team. When SecOps has these threats prioritized, significant risks can be lowered proactively.

In this first post regarding the OWASP Top Ten, we will dig into the top culprit in the list — Injection.

What is Injection?

OWASP defines an injection as “untrusted data sent to an interpreter as part of a command or query.” This means an injection occurs when the input to a web page from a source does not follow the ‘intended’ rules of what is expected, and that entry is made for the purpose of performing a command against a system. Now, that’s a mouthful – so let’s break that down a bit.

Imagine the input below. ‘Normally’ anyone would expect that the input is just going to be a username because that is what is being asked for. However, what if the entry was a statement which the system can interpret as code and not as a name. This is the essence of injections. The statement is then relayed into the program and causes a process to occur which the programmer(s) did not intend.

In the example above, the right hand side is asking the interpreter if “Is the user name Peter in your list, or does 1=1?”. The interpreter is looking to identify true statements. Maybe ‘Peter’ is a listed user, but definitely 1=1. And this is the beginning of where SQL injections affect a company’s data. If 1=1 was accepted, a hacker then can attempt more nefarious actions.

There are different SQL commands which can be utilized to affect the data. For instance, “DROP TABLE” is used to delete an entire table of data. Thus, a command as shown in this example could be a severe problem, deleting the entire ‘Customers’ table.

Peter’ or 1=1; DROP TABLE Customers; #

Image credit: Randall Munroe – XKCD

Prevent Injection with Input Validation

So, what seems like a simple fix is to make sure the input is checked and fits a model based on the requested input. The system is asking for a username. Typically, usernames have alphanumeric characters and possibly some symbols. How many times have you seen an email address as a username? Those usernames include characters such as ‘@’ and ‘.’. What about a hyphenated name, now we have to include ‘-’? However, if the programmer(s) did not set limitations for the allowed inputs, other characters can be included, such as spaces, apostrophes, quotes. All of these can be used to manipulate the intended input and affect the underlying system.

This is what is meant by ‘input validation’. There are multiple technical methodologies to solve this problem (safe API to avoid the use of the interpreter, white-list server-side input validation, limiting the amount of data returned from a query). However, at the core, all of these methods are performing the same process: examining the input entered to define if it should be utilized in part, at all, or if this is an attempt to hack the system. 

Additionally, Web Application Firewalls (WAF) detect attacks on your site by alerting you to injection attacks as well as other web-based attack methods. This is where our technology and squad model, working 24/7/365 come into play. We identify the alert, triage accordingly and escalate to you the presence of an attack, if one exists. This takes the burden off of your team and places these attacks in our arena where our elite teams make recommendations on what you can do to alleviate the problem.

Reduce Your Risk with Deepwatch

At Deepwatch, our customers count on us to fulfill the mission of protecting their networks and digital assets with world-class managed detection and response, endpoint detection and response, and vulnerability management. Stay tuned for coverage of the rest of the OWASP Top Ten in upcoming posts. For the complete list of Top 10 threats on web apps, visit OWASP’s website.

Subscribe to the Deepwatch Insights Blog

Post navigation

Previous post

Splunk Certificate Management

Next post

Healthcare Cybersecurity and Recent Ransomware Attacks

Deepwatch

DENVER
OFFICE & SOC

7800 East Union Avenue
Suite 900
Denver, CO 80237 USA
855.303.3033

TAMPA
OFFICE & SOC

4030 W Boy Scout Blvd.
Suite 550
Tampa, FL 33607 USA
855.303.3033

[email protected]

Why Deepwatch

  • Squad Delivery Model
  • Deepwatch SecOps Platform
  • Deepwatch Secure Score
  • Deepwatch Labs

Solutions

  • Managed Detection and Response (MDR)
  • MDR Essentials
  • MDR Enterprise
  • Managed Extended Detection Response (MXDR)
  • Endpoint Detection and Response (EDR)
  • Vulnerability Management (VM)
  • Firewall Management Solution

Company

  • About Us
  • Leadership
  • Careers
  • Contact

Resources

  • Resource Library
  • Insights Blog
  • News
  • Events

Partners

  • Channel Partners
  • Technology Alliance Partners

Contact

  • Let's Talk
  • Customer Login
  • Partner Login
GDPR Badge PCI Badge SOC2 Badge TRUSTe
LinkedIn Twitter YouTube YouTube

© Copyright 2023 Deepwatch incorporated

Trust | Sitemap | Privacy Policy