Weaknesses of signature-based API protection

WAF-as-a-service solutions are becoming an increasingly popular method for protecting websites and services running in the cloud. One significant advantage is the vendors' claim that security settings can be updated in time based on the data from incoming attacks that are caught. However, the question arises: how effective and inevitable are current WAFs and WAF-as-a-service solutions?

It is essential to address this issue as injection attacks are a prominent feature in the periodic OWASP Top 10 list, ranking 1st in 2013 and 2017 and 3rd in 2021, after broken access control and cryptographic failures.

Autospear: the new generation of SQL attacks

At the Black Hat Asia conference in May, researchers from Zhejiang University in China presented a new automated SQLi method for testing and bypassing signature-based WAFs. The method consists of using algorithms to modify the code originally intended to be injected – which is detected and blocked by firewalls by default – until it cannot be detected using the negative security model.

The modifications were as follows:

The point of the modifications, in this case, is that the SQL command will not change semantically, and the database server will be able to process it, but the signature-based protection can be bypassed. To do this, an algorithm is used that systematically maps which modifications can be run by trial and error and uses the feedback to design the code for the final attack.

The researchers tested the method on seven popular web application firewalls, four of which are available on Amazon Web Services as WAF-as-a-service. They focused on four types of requests (GET / GET(JSON) / POST / POST(JSON) and generated 10,000 unique codes from 100 known SQLi expressions.

The results suggest that WAF-as-a-service solutions can be attacked with high effectiveness, as there were vendors with 89% or more success using JSON payload.

Positive security model: protection against Autospear and other attacks

The positive security model has often been criticized for being more time-consuming and complex – and therefore more costly – to develop than the signature-based model. Still, it can provide much more effective protection against Autospear and similar attacks. With a properly designed and maintained API schema, the acceptable incoming data in a given field can be limited to the point where any modification that does not contain the expected data will immediately block the call. For example, in a userid field, you can specify precisely where and what characters are expected, their length, and composition.

This takes time and expertise, and needs to be tailored to the specific API in each case. It is not a switch that, when flipped, can give a false sense of security that you are protected against OWASP Top10 vulnerabilities.

Another severe criticism is that the positive security model gives too many false positives, though this problem can be avoided using expert-created and maintained templates and continuous feedback during testing.

However, a proper API security solution can help you to build your positive security model effectively. It is essential to ensure proper logging is in place during the development and testing phase. This can help you picture what your core traffic consists of and what vulnerabilities exist. A positive security model also enables you to test existing – or possibly missing – traffic-based schemes under controlled conditions. You can provide appropriate feedback to your developers by filtering out any calls that may occur that do not conform to the scheme. This can be recorded in log files in a developer environment with accurate feedback without interrupting the call. In a live system, you can immediately cut off the call without feedback or send a misleading message to the attacker.