my cheat sheet on API security

Home

1 Web application security

Web application security relies on a couple of components.

Same-origin policy, for example, is one of the basic approaches of identification assurance.

Once a web client has permission to access the content of a website (such as https://example.com), then the content from any URL will share these permissions. This can happen if the following components of the URL are the same:

  • URI scheme
  • Hostname
  • Port number

If any of these three components are different from the trusted URL, then the permission is no longer granted.

2 XSS

Cross Site Scripting is malicous javascript code that can be injected into a web server offering pages to clients. Then the client browser executes the java script. "An attacker executes malicious scripts in the web browser of a victim"

This can only happen if:

  • the victim visits the compromised page of the web server.
  • input scripts on web pages have vulnerabilites
  • web server has untrustworthy code, that lets them composes unstrustworthy web pages sent to clients
  • web server fails to sanitize user inputs that can then be rendered for viewing by other users, and/or executed within the page context
  • web server fails to sanitize queries before rendering them on response pages. i.e. a javascript can be sent in after the ? field, which can conatin encoded javascript code.

If that happens the attacker gains access to the user's cookies, and other session information, including tokens. The attacker can later reset tokens and get new ones, that the user does not know about. This lets the hacker assume the identity and thus assume the user's priviledges

The most common XSS attacks occur on web pages that grant user comments and web forums.

XSS.png

Figure 1: Cross Site Scripting

2.1 Most common XSS Attack Vectors

  • Stored XSS attacks occur when the injected malicious code is stored on the targeted web application server (such as the database). Once the request for the stored information is made, the victim unknowingly executes the malicious script. Also called Persistent XSS
  • Reflected XSS issues are those where user input in a request is immediately reflected to the user without sanitization. The injected malicious code is reflected with any response from the web server that consists of the input sent to the web server.

    The attack is distributed to the victim in a different way, usually in an email message. Once the victim clicks the link, the malicious code navigates to the web page. This action reflects the attack back to the victim web browser, which then executes the malicious script, because the script came from an already trusted web server.

  • Other XSS attacks (such as Document Object Model [DOM]-based XSS).

The attacker can gain the user's identity, and if the webpage was a bank, can withdraw or transfer money, close accounts. etc.

2.2 XSS Prevention

Proper use of good frameworks do the santization for you. So, do things like:

  • turn off HTTP TRACE. this denies all untrusted data into the web page HTML document, and denies all escape tags (HTML, Javascript, css (cascading style sheets) all use escpae tags, but users entering a comment or filling out a form should NOT be sending escape tags, only characters.
  • limit encodings on web page input fields and forms. (encoding could try to hide what the attacker is trying to do.)
  • santiize input fields (i.e. insist that ONLY characters and number can be input)

Here is an example of a stored XSS attack 

<html>
<script type="text/javascript">var attack='../hack.php?cookie_data='+escape(document.cookie);</script>
   </html>

2.3 Further Reading:

A couple of good links:

3 SQL Injection

The second most common web app attack is SQL injection. The attacker inserts an SQL query command into an web page's input field (comment, or form). If the web server does not sanitize this input field, or form, but rather just interprets the input, it could execute the SQL query commands.

sql-injection.png

Figure 2: SQL Injection

So an attacker could steal the entire database, or parts thereof, or modify his salary (add an extra 0), or worst of all, can get SQL to execute a system command (rm -f /*) etc.

For example the attacker inserts a metacharacter in the data input fields, which puts SQL into the control plane. Bad. Very bad indeed.

SQL injection comes in 3 types:

  1. In-band SQL injection is the most common and the easiest to exploit. It happens when the attack can use the identical communication channel to initiate the attack and collect the desired data. Error-based and union-based are the two most common subtypes of the in-band SQL injection.
  2. Inferential or blind SQL injection takes longer to exploit compared with in-band, but is just as malicious. No actual data is sent to the attacker, and the attacker cannot see the result right away. However, the attack can change the structure of the database. Boolean-based and time-based are among the most common subtypes of the inferential SQL injections.
    1. Out-of-band SQL injection happens when the attacker cannot use the identical communication channel to initiate the attack and collect the results. Because it relies on enabled features on the database server applied by the attacked web application, it is not commonly used. This technique depends on the capacity of the database server to issue DNS or HTTP requests to get a hold of the desired data.

3.1 Preventing SQL Injection

  • Sanitize any input data that can come from a user
  • Use prepared SQL statements, NOT dynamic SQL
  • Specify output data, so you do NOT leak any sensitive data

Example of an SQL injection:

  • SELECT * FROM Users WHERE UserID = 20 OR 1=1;

Because 1=1 is always TRUE, and you have OR 'd them together, that SQL statement is always TRUE, so you will have selected absolutely every user in the database. Imagin if the USERS table contained passwords as well.

4 CSRF

Cross Site Request Forgery attacks occur when an attacker forces a victim to issue undesirable actions on the victim-authenticated web application.

For most sites, browser requests automatically include any credentials associated with the site, such as the user’s session cookie, IP address, Windows domain credentials, and so forth. Therefore, if the user is currently authenticated to the site, the site will have no way to distinguish between the forged request sent by the victim and a legitimate request sent by the victim.

THe attacker tries to trick the victim via social engineering, or phishing, to click a link, where then the victim unknowingly submits a forged request. The CSRF attack can also be stored inside an image tag, a hidden form, or a JavaScript XMLHttpRequest object, which makes it harder for the victim to detect the attack, as it is done on a legitimate web page and not some random page. The attack exploit the web apps trust in a user browser, wheraas in XSS, the use trust of a web app is exploited.

csrf.png

Figure 3: CSRF, Cross Site Request Forgery

4.1 CSRF Prevention:

  • introduce a unique and secret token with every HTTP response, known as an antiforgery token.
  • antiforgery tokens are usually random numbers that are stored inside a cookie and stored on the web server.
  • The tokens are validated from the server. If the tokens match on the cookie and on the server, the request is accepted.

5 SSRF

Server Side request forgery vulnerabilities allow the attacker to send a forged request from a web server, on behalf of the attacker. The targets are usually behind a firewall, The web application request sometimes retrieves external information from a third-party resource (such as updates), and the attacker can modify or control such requests. The attacker also can:

  • read internal resources and files from the vulnerable server
  • scan local or external networks.

swarm.png

Figure 4: Swarm

5.1 SSRF Prevention

  • ensure the server retrieves external resources from only a list of allowed domains and protocols.

6 Securing & Scaling Application Ingress Traffic*

  • web apps need to scale, and be secure as the scale, so SSL offloading can be used aid in the high encryption load. SSL offloading can be done in two ways, typically by a load balancer on the edge of your network.
    • SSL termination A load balancer, or proxy server terminates the SSL session, i.e. the traffic is un-encrypted, and then sent to the final web server in the clear. Thus the web server never deals with encrypted traffic.

ssl-term.png

Figure 5: SSL Termination
  • SSL bridging A load balancer or proxy server just changes the data encryption. Instead of sending the traffic requests forward via HTTP, SSL bridging usually re-encrypts the traffic with Rivest, Shamir, and Adleman (RSA) keys.

ssl-bridge.png

Figure 6: SSL Bridging

6.1 Public SSL/TLS certificates

It is also possible to change the public SSL/TLS certificates once they reach your local network to private certificates.

A SSL/TLS certificate joins together:

  • Hostname, server name, or domain name
  • Identity and the location of an organization
  • A public key of the web application or page

Public facing web pages use the public SSL/TLS certificates. Public policy updates means these certificates need to be changed more often.

Private certificates are still approved by a certificate authority, CA. However, the biggest difference is that private certificates can be used for server to server communication and for non-registered private network domains.

7 WAF

  • Web application firewalls operate on layer 3 to layer 7
  • sit in front of a web server
  • do the things a network firewall cannot, i.e. at layer 7

8 Reverse Proxy Scrubbing

A reverse proxy server, sometimes called a surrogate, resembles a traditional server. It forwards requests to a traditional web server (or multiple servers) that later deals with the requests. The server then responds back to the reverse proxy server, which handles and returns the request to the user. However, the user does not know that the request came from the proxy server. A reverse proxy server handles the application ingress traffic in many ways.

reverse-proxy.png

Figure 7: Reverse Proxy Scrubbing

Handles these:

  • SSL encryption offload
  • no need to have multiple certificates, one for each server
  • load balancer
  • cache for static content
  • protect the web servers from OS attacks

What it cannot do though is protect the web application itself.

9 Load Balancing

9.0.1 Layer 4

  • simple
  • each remote user gets sent to one of the real servers, and only one.

9.0.2 Layer 7

  • complex, as content of each reqeust is examined, and load balanced based on this content
  • for example requests for videos are sent to real servers that handle video, and purchasing requests are sent to real servers handling ecommerce

9.1 Load Balancing Algorithms:

  • Round Robin (the default): simplest, can lead to unbalanced load
  • Least Connections: each server ends up with ~ equal number of connections
  • Source IP: a hash of the client's ip address dictates the real server)
  • Sticky: each user connects to the same real server when web apps demand it. (user session is lost when server dies)
  • health check: each server is checked for health, and if not health is taken out of the pool.

10 Securing and Scaling DNS

  • DNS is the most attacked server on the internet.
  • Public DNS servers should NOT use recursion, so keep your internal DNS records

off the public DNS server, and don't let those recursively query internal DNS servers.

  • Do implement redundant DNS servers, in high-availability pairs.
  • Authoritative name servers cannot be used as recursive servers.
  • Zone transfers between name servers need to be secured by access control lists (ACLs), to prevent DDoS attacks.
  • Internal secondary name servers must refuse all zone transfer requests

~

  • Implement Domain Name System Security (DNSSEC) extensions, to provide secure trustworthy DNS queries

    DNS information is digitally signed by DNSSEC and makes sure that end users connect to legitimate web pages or services depending on a domain name. This process is done via public key infrastructure (PKI). A link of assurance between the head of the DNS tree and the bottom end nodes is created from the root server digital certificate to the name server.

11 Parameter Sanitization

11.1 Home