Security in the development of Web APIs is no different from other areas of computing: we are dealing with messages between two parties (let us call them Alice and Bob), and a third party (call her Eve) which wants to either know what Alice and Bob are talking about, or wants to impersonate either Alice or Bob and trick them to do something. In this case, Alice is a client (carbon-based or silicon-based), and Bob is a Web API.
The first thing to consider is: can Eve intercept messages between Alice (the client) and Bob (the API)? If the communication between the two of them takes place over HTTP, then that means that all communications are insecure by default, and a simple network sniffing will suffice for Eve to inspect all the communications between Alice and Bob.
It is therefore the first rule of web development (aside from the rule which says that you don't talk about web development) that if the communications between Alice and Bob are not meant for Eve to see, then they must take place over HTTPS. This is expecially true for requests where Alice is sending Bob her username/password combo.
APIs which deal with any sensitive data should therefore always use HTTPS, and should reject requests coming in over HTTP.
Even if Alice and Bob use HTTPS for their communications, there are still several common security vulnerabilities which could compromise their interactions. The ones we will cover are:
- SQL Injection
- Cross-site Scripting (XSS)
- Cross-site Request Forgery (CSRF, also called See-surf)
We will also take a quick look at CAPTCHA as a security measure.
SQL injection has been the most common security issue in web applications for a long time.
In short, if our application contains code which uses input from users/clients directly when issuing SQL commands, then our app is vulnerable. However, if we use EntityFramework to handle SQL commands, then our app should be safe, since it enforces encoding of parameters in SQL commands. We should however always be aware of the risk, both when using EntityFramework and when using other ORM tools.
It is possible to execute direct SQL commands using the EntityFramework. Assume that the following (buggy!) method exists (please don't write code like this...):
public CourseDTO FindCourse(string strSearch)
{
var db = new AppDataContext();
var result = db.Database.ExecuteSqlCommand("SELECT * FROM CourseTemplates t WHERE t.Name LIKE '%" + strSearch + "%'");
// TODO: process the results...Assume that this method is wired to a HTTP api method such as /api/courses/search, which accepts a JSON object:
{
"search": "a'; DROP DATABASE; --"
}If the search method above would be executed, the query sent to the database would look like this:
SELECT * FROM CourseTemplates t WHERE t.Name LIKE '%a'; DROP DATABASE; --%'Notice how the SQL comment (--) ensures that the command is valid, otherwise a syntax error would have been thrown by the database.
To ensure this won't happen, all input from users must be escaped. For instance, single quotes from users must never be allowed to be interpreted as a part of the SQL command, and should always be interpreted as data.
In this particular case, the hacker is trying to perform an operation which should never be executed (DROP DATABASE/DROP TABLE etc.). Our database connection should of course be configured such that the database user doesn't have such permissions, but that does not solve the problem by itself.
Often, applications must accept input from users (say, comment on a discussion board), store that input in our database, and then return that input to other clients. Those clients may render the input in an HTML page. However, if a malicious user posts input such as:
<script>doEvilStuff();/* some more code which specifies what that function does */</script>;and that input is then rendered as HTML, then it will be executed on all clients requesting that data (such as for all clients viewing that discussion board).
It is therefore also important that such input is escaped, in this case by converting the "less-than" and "bigger-than" characters to their HTML entities, such as < and > This is also the reason why tools such as Markdown are becoming increasingly popular.
When a hacker targets this vulnerability, there is no un-encoded data involved. In this case, the scenario is like this:
- Alice opens website A, for instance a Single-Page Application, which connects to some Web API B.
- Alice authenticates via some means. A cookie is issued for Alice, and contains either a token or some session ID. Cookies are issued per domain, in this case "web.api.for.A.com".
- The next time Alice uses A to perform some operation in B (say, /api/courses/{id}/grades - PUT, because Alice is a teacher), the cookie is passed along with the request. B knows that it is Alice which is performing the action and sees that she is allowed to update the grades in the given course.
- Alice opens a malicious website E. This website was created by Eve, a student in the course Alice is teaching. Note that this website may be on a totally different domain than A.
- E contains code like this:
$(document).ready(function(){
$.put("https://web.api.for.A.com/api/courses/12345/grades", {
student: "Eve's ID",
grade: "10"
});
});Because the PUT request is being made to the domain of the API, and Alice has a valid cookie which the browser sends automatically with each request to that domain, Eve has thereby "tricked" Alice to update her grade without Alice knowing anything about it.
There are ways around it. The best method is not to use cookies at all, but explicitly include authentication details in the HTTP header of each request. This has its own set of downsides, but at least it prevents the CSRF attack.
Another option is for the API to have a "whitelist" of clients which are allowed to perform given/all operations.
The Open Web Application Security Project (OWASP) is a 501(c)(3) worldwide not-for-profit charitable organization focused on improving the security of software. Our mission is to make software security visible, so that individuals and organizations worldwide can make informed decisions about true software security risks.
OWASP Top 10 - The Ten Most Critical Web Application Security Risks
This is a very handy guide of the then most critical (and common) web application security risks. So it is very handy to read it and keep it around for reference.
sqlmap is an open source penetration testing tool that automates the process of detecting and exploiting SQL injection flaws and taking over niche features for the ultimate penetration tester and a broad range of database servers. It comes with a powerful detection engine, many of switches lasting from database fingerprinting, over data fetching from the database, to accessing the underlying file system and executing commands on the operating system via out-of-band connections.