By: Phillip Sharpless
Security, as part of many projects, is all too often an afterthought. The standing up of a new system or the development of a new project can be quite rapid and dynamic. Not pausing during this process to think about security as an integral component can be dangerous and a very expensive oversight.
A recent study by IBM found the average cost of a data breach in the US to be about 8.2 million dollars. When factoring in damage done to reputations and potential loss of future business, a high profile security breach’s true cost can be hard to even fathom. The same study estimated that a typical company has a roughly 30% chance of experiencing some sort of data breach in the next 24 months.
Given the high-stakes nature of data breaches, security must be treated as a central pillar in the development and maintenance of any system. All individual components of the solution must be secured, as well as any interactions between them. A single weak link in the chain represents a potential data security threat.
As a web developer, one must understand that web applications are usually one of the first places a malicious user will attempt to penetrate. As such, it is a necessity to have a thorough understanding of the most common types of attacks done against web applications.
In this blog post, we’ll briefly touch on the two most common attack techniques: SQL injection and cross-site scripting (XSS).
Understanding how these attack techniques work (conceptually) will help developers avoid the types of mistakes that make apps vulnerable. Those two potential attacks (as well as most other attacks against a web site) ultimately stem from the same issue: failure to validate and sanitize inputs taken from the user. Any piece of data supplied by an outside user or system, no matter how innocuous, should be viewed as a potential security threat and thus that input should be treated with great care.
SQL Injection
One of the oldest, most common, and most dangerous web app vulnerabilities is that of SQL injection. To understand it conceptually, imagine a very simple page where customers are given the ability to enter an order number to pull up their order information.
One might take the input value from the user and place it in a query to fetch information from the database.
|
1 2 3 |
SELECT * FROM Orders o WHERE o.OrderNumber = <theUserValue> |
This seems straightforward and when tested it appears to work as expected. Users enter their order numbers and see the appropriate data. However, savvy users can almost instantly imagine how this particular search may be implemented. Imagine if the submitted input field contained: 20795 OR 1=1
The resulting query would be:
|
1 2 3 |
SELECT * FROM Orders o WHERE o.OrderNumber = 20795 OR 1=1 |
This query now returns true for every single row in the orders table. By taking the user’s input and simply dropping it directly into a query, you’ve essentially opened the door for the user to run their own queries against your database. With clever escaping and encoding of commands, a bad actor can potentially query any table, or even drop tables or the entire database.
That is SQL injection in a nutshell. Essentially any time you take input from an outside source that could potentially be used in database queries or commands, the input must be properly vetted. Most major database frameworks now provide support for secure parameterized statements, which should be the default way of doing these queries.
Cross Site Scripting (XSS)
The other very common web-based attack is that of cross site scripting. It essentially stems from the same root cause as SQL injection: user input not being vetted and then being used in a malicious way.
Many websites give the user the ability to add their own content to a site in some way. Something as simple as the ubiquitous “Comments” sections is a good example. The user is expected to enter a comment and that comment will then be embedded in the page going forward for future users to see. Instead of a simple comment, imagine if a user enters something like:
If this input is accepted as is and blindly reflected within the site, you’ve potentially given users the ability to embed their own JavaScript within your website. This can allow for malicious actors to vandalize the page, redirect away from the page, or even to hijack other user’s sessions or credentials.
As with SQL Injection, the lesson is the same. Any time input is being taken from an outside source that could be reflected back within a webpage, it should be properly encoded to ensure someone does not have the ability to inject their own custom HTML within the page.
Conclusion
There are a wide variety of other web application attack technique besides the two I’ve just mentioned, but most of them still boil down to the same issue: input taken from a user being used in an unexpectedly insecure way. Any piece of data taken in from the web application should be viewed with caution. Always stop to think about what the input is being used for and how it could be misused. Then guard against that scenario.
Web applications often serve as the front door to a much larger system backing them. Ensuring that front door is “locked” is a great first step to maintaining a secure environment. Of course each part of the solution should also be independently secured to maximize the overall security of the system. For example, the databases themselves should be secured and all highly sensitive data should be properly encrypted or obfuscated. This sort of data security in the backend provides security redundancy, ensuring that even if (heaven forbid) an access breach did occur, the data would still be secure. Stay tuned for more posts in the future diving deeper into data security concepts.
References
Cost of a Data Breach Study 2019 – IBM: https://www.ibm.com/security/data-breach
Open Web Application Security Project (OWASP): https://www.owasp.org/index.php/Main_Page
SQL Injection Examples: https://www.w3schools.com/sql/sql_injection.asp
Excess XSS: https://excess-xss.com/
Questions?
Thanks for reading! We hope you found this blog post to be useful. Do let us know if you have any questions or topic ideas related to BI, analytics, the cloud, machine learning, SQL Server, (Star Wars), or anything else of the like that you’d like us to write about. Simply leave us a comment below, and we’ll see what we can do!
Keep your data analytics sharp by subscribing to our mailing list
Get fresh Key2 content around Business Intelligence, Data Warehousing, Analytics, and more delivered right to your inbox!
Key2 Consulting is a data warehousing and business intelligence company located in Atlanta, Georgia. We create and deliver custom data warehouse solutions, business intelligence solutions, and custom applications.