Much has changes and much has remained the same in the vulnerability assessment space. Frameworks, having introduced neat new ways to create vulnerable code, have again managed to cover their tracks and clean up many of the ways we can shoot ourselves in the foot by unintentionally writing insecure code. However, some of the old favorites have reared their ugly heads.
Access Control
You know the whole "we rolled our own encryption" thing that makes security people tear (what's left of) their hair out? These days I am hearing a lot of "We rolled our own Oauth2." Corporate has decided we are using Ping for auth this week, and so all the apps have to use it. But, the developers don't like Auth.js because it is spaghetti code, or Spring Security doesn't do what they want, or whatever. But then bits get missed, because frankly Oauth2 is hard.
Mostly what is showing up is information leakage and insufficient session expiration. It is really easy to leave important information in the communication with the authentication service. And honestly, I don't even completely understand how refresh tokens are REALLY supposed to work. That whole thing is overdesigned, and it is hard to implement.
Supply Chain
I probably don't need to tell you that there are supply chain problems. GitHub is under attack, npm is a dumpster fire, we don't know on an app by app basis what parts of shared libraries are actually being used, and few update when they should. Much has been said, but I'll just link you to Kevin Wall discussing the topic at OWASP Global Appsec 2023,
https://www.youtube.com/watch?v=OF2WluHxQnk
In short, what can be done quickly to combat all of this is:
- Don't use every shiny nickel library when it comes out. Use what you need and stick with it.
- Keep stuff up to date.
- Run static code analysis. If you are low in the budget department, there are open-source products available.
Update after xz.utils weekend: clearly there is more to be said here. Separate blog post coming.
SQL Injection
A lot of current libraries are using GET parameters for things that should be POST parameters again. Not sure why that is happening yet exactly, but I'm working on that. Anyway, this is causing a rash of SQL injection findings because folks apparently are under the impression that GET parameters aren't vulnerable to injection.
If you are sending a value from the browser to a third system, it is injectable. It doesn't matter if it is a POST parameter, a GET parameter, or an HTTP header. And if I can create a database error, I can break into your database.
All queries to anything need to be parametrized. XML, document databases, JSON, and of course relational databases with a database management system are all vulnerable to injection. Input validation doesn't work. Encoding doesn't work. A whitelist in the user interface doesn't work. Only parameterized queries work. Use them.
Cloud
Two particular findings are showing up a lot of the overall move the PaaS and SaaS cloud services. The first is leaking API keys. Folks leave them in comments, or pass them in requests that are not visible to the user (but are to the attacker.) There are a lot checked into source control too. Don't lose access to your whole platform - set up authorization just in case, and of course don't leak the keys. That subscription-id in Azure is important. Keep them out of the attacker's hands.
Source Control
I sorta mentioned this in Cloud and Supply Chain above, but there is more. Folks are working really really hard to try and open source parts of their corporate projects because it is the cool thing to do. (It really is pretty cool.) However, things get checked in that shouldn't be (look at your configuration files for ASP.NET, Gradle, or whatnot.) What's more, reverting the change doesn't so much remove it from the source control database. I have taken to going and looking through history of the project as part of an assessment's reconnaissance phase just to see what I can find.
Verbose Errors
Another artifact of changes to new hip platforms is lacking global error handlers. If I can sufficiently confuse the application, and get an error sent right from the web server rather that the application's code, it probably has something in it that I can use in further attacks. They has to be a global, if all else fails, exception handler in each application. The event to tie that to is a moving target but take a minute and figure out where you have to handle that and do it. Don't give away free information.