Software Craftsman, Young Curmudgeon

Web API Application Security

    dev softwaresecurity  

Notes taken from the 2-day workshop for Web API Applications Security: Attack and Defense from NDC Copenhagen 2020 held online on April 2020; this focuses primarily on practical application security on Web Applications whereat different attack vectors and mitigation techniques are reviewed.

Content was divided into the security topics: HTTP Protocol, SQL Injection, XSS where the latter is divided into different subcategories.

HTTP Protocol

A few best-practices to consider for both directions, request and response; we must always keep in mind the side-effects and limitations mitigation mechanisms might bring and ultimately impact the system functionality.

HTTP Request

Some considerations:

Although HTTP GET requests are encrypted in transit, there are still some other ways information contained in it can be leaked:

As far as HTTP Referrer Headers, tweaking the Referrer-Policy HTTP Header or using the rel="noreferrer" in hyperlinks is a start to mitigate such issues.

HTTP Response

The response side is where we can some kind of control over the client, though we still depend on the client compliance to standards and not doing their own thing; some security considerations on this side are:

The usage of this header is discouraged as browsers are dropping compatibility as it is not a standard header; as a matter of fact, the usage of the CSP header is favored.

e.g.

Expires: -1
Cache-Control: no-store, no-cache, must-revalidate
Last-Modified: now
Pragma: no-cache

X-Feature-Policy is still experimental at the time of this writing.

SQL Injection (SQLi)

It was mentioned as a recommendation, the following algorithms for password encryption when storing them in the database: bcrypt and scrypt.

Parameter sanitization and good access control are among the common mitigation techniques, still, we are given the following best practices:

In addition, some of the attacks known using this vector:

XSS

Among the defense mechanisms, we’ve got the following:

The following matrix was presented which encapsulates where we can use the different mechanisms:

Data Type Context Defense
String HTML Body / Attribute HTML Entity/Attribute Encode
String Javascript variable Javascript Hex Encoding
String HTTP GET parameter URL Encoding
String Untrusted URL URL Validation, avoid javascript: links, Attribute Encoding and Safe URL verifications
String CSS CSS Hex Encoding
HTML Anywhere HTML Sanitization (Client and Server side)
Any DOM Safe Use JS APIs
Untrusted Javascript Anywhere Sandboxing & Delivery from Different Domain
JSON Embedded JSON Serialization

A bit more on attacks, we’ve got the types: Reflected & Persisted, in esence the difference being that the persisted, as the name implies, sticks beyond the user requests or sessions, likely put in place through some feature of the Web Site or Application.

Now, some example of attacks:

With XSS, for the most part it is about what we can trust and where in the stack we’ve got enough control to put safety mechanisms in place; he are some assumptions:

All protections must be built within the UI layer itself such as escaping, encoding/decoding, sanitization

DOM XSS

This requires unexpected modifications to the actual DOM structure rendered at the client, this is considered as yet another type in addition to reflected and persisted; [IFrame Sandboxing][html5rocks-iframe-sandboxing] can help us to dramatically reduce risks when running 3rd party components on our applications.

More information about [DOM-based XSS][owasp-dom-xss].

Tools & Frameworks

There we some tools and frameworks mentioned that are worth looking into:

References