Back
Tales From the Road: Think Your Web App is Hacker-Proof? Think again…
Mobile apps have become the preferred choice for today’s consumers, with web app usage taking up 90% of all mobile uptime – more than the entire browser-based internet as a whole – and it’s easy to see why. Mobile apps provide a better user experience compared to mobile browsers and desktops thanks to the ease-of-use, speed and personalization that comes from, you guessed it, saving user data. Unfortunately, this comes with a risk, as we saw first-hand when we put one client’s web app to the test.
Spoiler alert! The overall threat exposure for our client’s web app assessment was ranked at a “severe” level of risk based on failing 7 out of the 10 security risks on the OWASP 2017 Top Ten.
Keep reading to learn how you can address the top web application security threats to keep your users’ personal data safe from hackers.
The Tip of the Iceberg: Preventing SQL Injection Flaws and Weak Authentication Controls from Compromising Your Web Applications
A luxury rental operator enlisted our services to perform a comprehensive web application security assessment/penetration test of their web application. With members across the country and significant data being shared to enable the process, it was important for the security of the application to be verified.
Our team rolled up their sleeves to simulate an attacker attempting to gain, or elevate, access to the application and its sensitive data through a series of security tests against the web application. As mentioned earlier, many threats were found. Here, we will cover the top two – which happen to be the most common web application vulnerabilities.
Threat #1: SQL Injection Flaws
SQL injection is one of the most impactful and worst threats you can find, and we found it! In our testing, we uncovered multiple SQL injection flaws which could compromise the users and the application, allowing an attacker complete access to the sensitive information within the database with the potential to backdoor the server with enough time.
Using a member account from within the application, our team was able to dump out all the data from the entire user database and get everyone’s credit card information! Virtually any user logging into the application would have the same ability, giving them access to all sorts of sensitive data including, but not limited to, usernames and password hashes, appointments, email addresses, phone numbers and credit card information.
How to Avoid it: Failing to properly handle user-supplied input prior to passing information to the database exposes the database to a malicious user via SQL queries. We recommend that the company review all application modules that interact directly with the back-end database and implement properly prepared statements for database queries. In addition, they should consider adopting a coding standard that includes specified functions for the creation of safe SQL queries, whether that be ORM functions, parameterized queries or stored procedures.
Threat #2: Authorization Bypass
We also discovered that the web application exhibited multiple authentication issues which could compromise user accounts and potentially sensitive data. For starters, the application didn’t require authentication to access sensitive functions within the application, giving an attacker free reign to make changes to the application data and state without needing credentials.
Additionally, the application didn’t perform proper authorization checks on HTTP requests to ensure that users of a specific role are validated to fulfill certain requests. With role authentication left unchecked, an attacker would have the authority to make changes to the application without needing higher-level privileges.
How to Avoid it: Deficiencies in authentication could be a result of improper server configuration or failure to enforce authentication prior to resource access. Insufficient authentication is identified most prevalently in supporting web services, upload or download content and obscure/hidden resources located in an accessible directory. The majority of issues stem from the often-misused principle of “security through obscurity.” Pro tip: Merely hiding or not exposing a resource via a link will not adequately protect the intended resource.
To ensure all sensitive resources and functions are properly protected, we recommend that the following authentication and session management controls be implemented on each request:
- Unique user names for all users
- Passwords complexity enforced with at minimum the following rule sets:
- At least 1 uppercase character
- At least 1 lowercase character
- At least 1 digit
- At least 1 special character
- At least 8 characters long (12 or higher is preferred)
- Ban common password variants and dictionary words
- Password changes occurring every 90 days
- Account timeouts and lockouts rules should be implemented and enforced
- Require re-authentication for sensitive functions (user profile modification, purchases, password changes, etc.)
- Credentials should be transmitted over secure channels
- Credentials should be stored encrypted and passwords should use one-way hashing
A Security Breach is Much More Costly than Fixing Your Web Application
Many times (as in this case) a company inherits a web application with security issues; in this case, the app wasn’t coded right to begin with. This is a perfect example of why it’s so important to do your due-diligence before the acquisition of a company and its web assets.It’s not uncommon for a company to know about security issues with their web app, but leave them un-fixed due to a lack of time, resources or budget. Take our word for it: It is much less costly to take the steps now to ensure that your web app is secure, than to suffer the monetary and reputational damage that a security breach will surely bring.
Don’t let your web applications threaten the security posture of your reputable organization. Contact DirectDefense to put your web applications to the test today!
06.17.21