Web applications can be one of the biggest threats to your internal network. I would argue that in the majority of our external penetration tests, where we escalate to the internal domain, a web application is to blame. It seems there are a few gaps that people are missing when conducting their own web application penetration tests. This post aims to close a few of those gaps with some recommended testing practices.
Here are a five items that we have been seeing recently, that you should be looking out for in your web applications:
1 – Mobile Testing
If you have a mobile app and it’s integrated into your web application (APIs, direct page requests, etc.), you need to be testing the pages/services available on the mobile side. Same goes for your mobile specific domains (ie: mobile.example.org). There seems to be an assumption that mobile pages are safer, due to the layer of abstraction provided by mobile devices. It’s not hard for an attacker to change their browser to look like a mobile device and attack mobile apps, just like they would attack regular apps.
2 – Fully Vetting Out SQLi
When you do identify a SQL injection vulnerability, make sure you are vetting out the vulnerability to determine how much impact the issue could have on your environment. Could the attacker abuse this to pivot to the internal network? If so, how would they do that? How much sensitive data could this expose? These questions should help shape your remediation efforts and potentially change the way you deploy your applications in the future.
3 – Test All the Apps
Internal, external, and anywhere else you have web applications, you should be testing your apps. On multiple occasions, I’ve seen simple applications (logging, metrics, etc.) that have major issues. Just because an application seems simple and/or isolated, it doesn’t mean that this application could be a threat to other hosts on your network. Priorities should be applied to important apps, but don’t forget about the little apps.
4 – Automated Scanners – Trust, but Verify
I mentioned this one in my “Network Penetration Testing Strategies” article, but this deserves repeating. You can typically trust (most) automated scanners, but they can be filled with false positives. Some web application scanners can be particularly bad about generating false positives. Even worse, the scanners may cause you to miss critical (entry point) vulnerabilities that don’t show up. Never underestimate a verbose error message. If you’re seeing database errors in verbose messages, you may have SQL injection available. On several occasions, I’ve seen automated scanners come back with low to medium severity “verbose error message” or “database error message” findings that contain database connection strings.
5 – Use the Search Engines
This can result in more configuration related vulnerabilities than anything else, but it turns out that Google is pretty good at mapping out your web application (external facing ones) for you. Use the “site:www.example.com” search to find pages within your site that are publicly listed. You may be surprised with what you find.
Hopefully, you’re already doing all of these steps during a web application penetration test. If not, I hope these gave you some insight into what’s working for us when we assess web applications.