![seurity]()
What is an AntiPattern in Software?
"An anti-pattern is a common response to a recurring problem that is usually ineffective and risks being highly counterproductive". In short, anti-patterns are commonly reinvented, but bad solutions to problems.
It's no surprise there are numerous anti-patterns in software security. Far from complete, here's a list of anti-patterns that capture the very essence of the most critical software security weaknesses.
- Pardon the malintent
- Copy-Paste insecure code
- Incomplete mediation
- Blacklisting
- Loosening blacklists
- Widening whitelists without precautions
- Insufficient WWW knowledge
- Secure library ignorance
- Mixing code and data
- Confirmation bias
Let's explain these anti-patterns giving specific details for each of them:
Pardon The Malintent
Exception handling is a vital way of providing fail-safe flows throughout the source code. Unexpected conditions are caught at runtime and appropriate actions are taken through exception handlers. Logging, notifications, releasing resources are some of the actions taken at the exception handler code.
The same care is usually not applied when it comes to producing alerts when there's a hacking attempt caught by the code. For example, in an XML parsing code, a DTD processing or an undefined external entity exception most likely means a hacker attempting to trigger a XXE.
A developer should log in and produce a notification when an attacker starts to play around with the product. Even more blocking actions might be taken. Instead of WAFs, the source code itself is a much better playground for such actions because of several factors including impedance mismatch.
Copy-Paste Insecure Code
Developers utilize copy-paste code big time. Sites like stackoverflow are popular for some reason. These sites are quite helpful when a solution to a problem is begin sought, such as; API usages, runtime errors etc.
Builders tend to quickly look for an accepted solution or a solution, copy-paste the code and move on should that solution work. However, not every solution is secure. Some of them open up new venues for attackers. Copy-paste solutions should be taken with a grain of salt (critical thinking).
Incomplete Mediation
Authorization is usually the key security factor of a software product. Not every resource should be reached or consumed by all users.
There are various cases where lack of authorization might allow attackers to access resources where they shouldn't.
For example, usually GET requests, triggered by generic URLs, are checked against authorization code, which applies the access rules, very well. However, these same access rules are usually forgotten against the relevant POST actions. However, it is rather easy for an attacker to forge a POST request.
Another example to incomplete mediation anti-pattern would be to forget to apply authorization checks against administrator interfaces or requests triggered by native mobile phone applications (who would or could fool around with mobile applications, right? wrong.).
Blacklisting
There are a handful of input validation strategies that a developer can utilize; blacklisting, normalization, whitelisting, encoding and such. However, the first strategy usually that comes to mind against a security problem is unfortunately the blacklisting.
It seems to be the easiest and most non-intrusive way of all the input validation strategies. However, it turns out to be the worst for security.
There are various sites for hackers that list a plethora of security control bypass payloads. It is really hard to form a solid, hackproof blacklist since the applications get more complex and the attackers/testers are smart when it comes to bypassing the filters.
Loosening Blacklists
There are a handful of input validation strategies that a developer can utilize; blacklisting, normalization, whitelisting, encoding and such. However, the first strategy usually that comes to mind against a security problem is unfortunately the blacklisting.
For simple applications blacklists may prevail against attacks, however, as the application gets heavier in complexity the filters get complicated. But still a huge and well-thought filter may seem to be successfull.
But sooner or later customers begin to experience problems when entering normal inputs and the Business gets oppressive. The result would be to remove some of the characters or words from the blacklist used without the awareness of the security teams if they exist. That leads to insecure days.
Widening Whitelists Without Precautions
Whitelisting is one of the best strategies of input validation since it means to accept the expected only. Not enough to make an application completely secure, it helps a lot and much, much more than blacklisting.
For example, it is easy to write a hardened regular expression for a username field, where the input comes from the user. It may as well be easy to write a nice secure regular expression for a comment field, too. However as the business requirements evolve more characters might be required to be in the safe list. The immediate response to this new requirement will be to include the "extra" characters in the regular expression.
An uncontrolled (without applying appropriate output encodings) widening of the whitelist regular expression will wipe out its security effectiveness.
Insufficient WWW Knowledge
Web applications rely on data sent through HTTP requests. With the popularity of browser developer tools more and more developers start to play with the raw HTTP requests and learn the basic blocks of web applications.
However, it is perfectly possible to implement a web application without seeing/analyzing a single HTTP request/response of it. The insufficient WWW knowledge sometimes mislead developers that end-users can't play with their parameters such as hidden parameters or HTTP 302 requests.
These hidden parameters or seemingly automatic requests are very well ablte to be intercepted by attackers and every single character of them can be manipulated. Without this undestanding solutions will be insecure.
A very good example would be 3D secure payment flows that involve the user's browser, the backend e-commerce application, the virtual POS server and probably the bank servers. Ninety-percent of the (hidden) traffic flows through the user's browser and ıs open to manipulation.
Secure Library Ignorance
A decent application is deployed with lots of third party plugins and/or libraries, both server-side and client-side. Apart from the security of the code written exclusively for the application, the security problems of these libraries are usually missed.
Worse yet, the security problems of these 3rd party libraries are mostly published and open to everyone's reading.
Mixing Code And Data
Maybe the worst anti-pattern in software security are the string concatenation operators or methods. Solving a listing of books searched by an end-user utilizing SQL statements dynamically formed by supplied search criteria is asking for a disaster.
Injection types of security weaknesses all stem from mixing the user controlled data with the code. There aren't many APIs provided by the frameworks or programming languages that have the ability to keep the data and code separate till the code gets interpreted. Prepared statements are one of the best examples of these lacking APIs.
Appropriate input validation strategies should be applied before uncontrolled mixing of data and code.
Confirmation Bias
Confirmation bias, also called confirmatory bias or myside bias, is the tendency to search for, interpret, favor, and recall information in a way that confirms one's beliefs or hypotheses, while giving disproportionately less consideration to alternative possibilities.
In short, it is a way of thinking that produces insecure code,
- failure of casting a parameter named "id" into integer, but instead assuming it to be an integer and dynamically constructing a SQL statement with it
- taking the second token as the file extension after a split with a "."
References
- https://en.wikipedia.org/wiki/Anti-pattern
- https://www.owasp.org/index.php/XML_External_Entity_(XXE)_Processing
- http://stackoverflow.com/a/21402736
- https://packetstormsecurity.com/files/112152/Cross-Site-Scripting-Payloads.html
- https://www.owasp.org/index.php/SQL_Injection
- https://en.wikipedia.org/wiki/Confirmation_bias