OWASP TOP 10

A07 – Identification and Authentication Failures

It is very important that sites you use are sure that it is actually you that are using it and not someone or something (like password robots) else.  Although it can be a pain to know your password, enter the code that sent on your cell or email, these measures help the sites to know it really is you.  There are many ways of authenticating a user.  Some include:

• biological things: retina, fingerprint, walking gait, signature pressure
• what you know: passwords, security Q&A
• others: cell phone, IP addresses, GPS locations, behavioral characteristics, app usage…

Too often sites or apps will let you guess over and over again your password (or username).  Further, many sites allow “extra” stuff in the username fields, like Username: “JSmith=Do this bad stuff”  JSmith was the username but since the field did not prevent hitchhikers on to the end of the username.  Good coding practices will mitigate this problem. 

At the end of the day, all of these things can be nullified if the user lets the bad actor in.  Innocently, many think the toll free “tech support” that alerted them to an issue (with their computer, bank account, app access) are legitimate helpers only to find their accounts drained.

A08 Software and Data Integrity Failures

Software and data integrity involves making sure the data or software, often updates, are really coming from the place they are supposed to.  It also involves making sure the right data or update arrived.  This vulnerability was widely seen with the Solar Winds attack.  The software performed updates, but they were not the correct update. 

Many programs rely on other programs to correctly work.  A flaw in one of the third party programs makes the “host” program vulnerable too.  Much of this vulnerability is mitigated by good programming practices and use of digital signatures.  This ensures the new data or code came from the expected source and meets integrity checks. 

Using the paddleboard example, I have a Jimmy Lewis paddleboard.  Now, that company does not manufacture the entire board and all of the parts.  Assume the pad is purchased from a third party.  If the company that makes the pad also outsources their rubber, and it turns out the supplier had a bad batch of rubber, the pad is then bad, it goes on the board and let’s say the rubber was slippery than it should be.  Now, the user falls off and gets hurt.  Not really Jimmy Lewis’ fault, but the overall name on the board is Jimmy Lewis. 

A09 – Security Logging and Monitoring Failures

There are a plethora of software and appliances for protecting all aspects of technology.  Whatever the method for tracking information and event management a client uses, these detection applications are not launch and leave processes.  They must be configured for an ever changing environment and over sought by people monitoring the logs and information they provide.  Too often, it is assumed that the device or software was installed and now it’s “doing its job”.  That is not the case.  Frequent monitoring and updating is essential to getting the most out of these systems.  Think of a cell calendar that keeps track of all of your upcoming events.  Now, lock it in the car and spend the day at the beach.  The calendar is providing notifications of the ten scheduled items you had for your day, but you are paddle boarding along the shore enjoying your day.  The device did what it was supposed to, but no one was there to make sure they happened. 

A10 – SERVER-SIDE REQUEST FORGERY (SSRF)

The bad actor’s goal is accessing a server that’s behind the scenes with limited approved users/computers.  As the actor does not have access to this server, they present a malware request to a server that’s running a website.  The website server makes a request of the back-end database server.  The back-end server trusts the website server and processes the request.  This is the essence of a server-side request forgery.

Much information can be collected through the course of this attack:

• open communication ports
• exposure of the data on the back-end server
• services that are running (providing further attack possibilities)
• cloud data or information about cloud usage

Preventative measures are focused mainly on improving the network and the applications.  At the network level, enforcing “deny by default” will go a long way.  Segmenting resources also limits exposure in the event of a breach.  Within the application level, multiple actions can be taken, including:

• not allowing one website to reach out to another website
• validating all data that users fill out in forms
• specify allow lists

To see samples of the many SSRF attacks this year, visit https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=SSRF