Functional Attack to API providers
We could have few security attacks to an API:
- SQL Injections
- Fuzzing
- Cross site forgery
- Session/token hijacking
SQL Injections
In this attack, the attacker tries to identify input parameters used in a SQL statement in order to manipulate the original query
Fuzzing
Fuzz test or Fuzzing is a black box software testing technic which consist to inject random data to a service in order to find bugs
A fuzzer would try combinations of attacks on:
- numbers (signed/unsigned integers/float…)
- chars (urls, command-line inputs)
- metadata : user-input text (id3 tag)
- pure binary sequences
A common approach to fuzzing is to define lists of “known-to-be-dangerous values” (fuzz vectors) for each type, and to inject them or recombinations.
- for integers: zero, possibly negative or very big numbers
- for chars: escaped, interpretable characters / instructions (ex: For SQL Requests, quotes / commands…)
- for binary: random ones
The hacker, then, analyse the response to understand vulnerability
So pay attention to which type of response error you send back. Don’t send, for instance, sql exception error.
Cross site forgery
In this case the hacker is able to execute a script, which call our API, using the user device.
To avoid this type of attack use POST instead of GET, split transactions in multiple step, add custom headers.
Token and Sessions Hijacking
This is basically a specialisation of the Cross site forgery, with the target of get the token saved on the client device.
So, the user in some way executes the attacker script which will read the token or the session cookie and use it to access to private resources
In this case suggestions are:
expire your token
use complex token pattern
use some additional security header, do not rely only on Access Tokens