Web Developer view on Security.md

HTTP Headers

• Servers can send HTTP headers to provide the client with additional metadata around the response. Besides sending the content that the client requested, servers are then allowed to specify how a particular resource should be read, cached or secured.
• They have been implemented by browsers in order to make it harder for attackers to take advantage of vulnerabilities.

HSTS

• HTTP Strict Transport Security.
• A simple Strict-Transport-Security: max-age=3600 will tell the browser that for the next hour (3600 seconds) it should not interact with the applications with insecure protocols.
• To Check: https://hstspreload.org/?domain=facebook.com
• Prevents: MITM, Eavesdropping attack

HPKP

• Dangerous and is adviced not to use.
• Many websites have been in-accessible because of a misconfiguration in this ex, Smashing Magazine.
• HTTP Public Key Pinning (abbr. HPKP) is a mechanism that allows us to advertise which SSL certificates to expect when a browser connects to our servers.
• Once the client connects to our server, it will store the certificate’s info for subsequent interactions.
• Prevents: MITM Attacks.
• Sample Policy:

Public-Key-Pins:
  pin-sha256="9yw7rfw9f4hu9eho4fhh4uifh4ifhiu=";
  pin-sha256="cwi87y89f4fh4fihi9fhi4hvhuh3du3=";
  max-age=3600; includeSubDomains;
  report-uri="https://pkpviolations.example.org/collect"

Expect-CT

• The goal of Expect-CT is to inform the browser that it should perform additional background checks to ensure the certificate is genuine.
• When a server uses the Expect-CT header, it is requesting the client to verify that the certificates being used are present in public Certificate Transparency (CT) logs.
• The Certificate Transparency initiative is an effort led by Google
  • An open framework for monitoring and auditing SSL certificates in nearly real time. http://certificate-transparency.org/
• If the client gets tricked into connecting to a malicious server, the attack will never work as the SSL certificate won’t pass the CT validation.
• Sample Header: Expect-CT: max-age=3600, enforce, report-uri="https://ct.example.com/report"
• Prevents: MITM Attack

XFO

• X-Frame-Options
• XFO lets you decide whether your app can be embedded as an iframe on external websites.
• X-Frame-Options: DENY
• Prevents: ClickJacking Attack

Content-Security-Policy

• What scripts/JS-code is allowed to be executed
• Report-only mode: Content-Security-Policy-Report-Only
• Policy Check:https://csp-evaluator.withgoogle.com/
• Policy Create: https://report-uri.com/home/generate
• Prevents: XSS Attacks, ClickJacking

X-XSS-Protection

• Suspended, used in older browsers that don’t fully support CSP.
• Prevents: XSS Attacks
• Do not use

Feature-Policy

• Feature-Policy: vibrate 'self'; push *; camera 'none'
• This header lets us define whether a specific browser feature is enabled within the current page.

X-Content-Type-Options

• MIME-sniffing is the ability for a browser to auto-detect (and fix) the content type of a resource it is downloading.
• X-Content-Type-Options: nosniff
• Imagine a user uploading a /test.jpg file that contains JavaScript code. As the browser downloads the image, it would detect that it’s a script instead, and execute it on the victim’s browser.
• Prevents: MIME-sniffing

Cross Origin Resource Sharing

• On the browser HTTP requests can only be triggered across the same origin through JavaScript. Simply put, an AJAX request from example.com can only connect to example.com.
• A set of directives that allow you to execute cross-domain requests.
• Access-Control-Allow-Origin: *
• Prevents: Stealing

Referrer-Policy

• Prevents: User Privacy

The reporting API

• Report-To

• A server can inform the browser to hand violations over at a particular URL.

• Reportings related to:

  • CSP and feature-policy violations
  • risky code: the browser will sometimes intervene and block our code from performing a specific action
  • deprecations: when our application uses an API that the vendor is planning to deprecate
  • crashes: when our application has caused the client to crash

• More on reporting api here

• Use https://report-uri.com/ for getting a uri to report if don't have personal reporting uri.

Testing for Security Posture via headers

• https://securityheaders.com/

---

HTTP Cookies

Basics on Cookies

• A server can send a cookie using the Set-Cookie header (Can send multiple cookies at a time).
• A client will then store this data and send it in subsequent requests through the Cookie header (Can send multiple cookies at a time).
• In addition to the plain key and value, cookies can carry additional directives that limit their time-to-live and scope.
  • Expires: Specifies when a cookie should expire, so that browsers do not store and transmit it indefinitely. access_token=1234;Expires=Fri, 24 Aug 2018 04:33:00 GMT
  • Max-Age: Similar to the Expires directive, Max-Age specifies the number of seconds until the cookie should expire. access_token=1234;Max-Age=3600
  • Domain: This directive defines which hosts the cookie should be sent to. A cookie with the directive Domain=trusted.example.com will not be sent along with requests to any domain other than trusted.example.com, not even the root domain, example.com. access_token=1234;Domain=trusted.example.com
  • Path: Path is similar to the Domain directive but applies to the URL path (/some/path). This directive prevents a cookie from being shared with untrusted paths. access_token=1234;Path=/trusted/path

Session and Persistent Cookies

• Session cookies: When a server sends a cookie without setting its Expires or Max-Age, browsers treat it as a session cookie. Rather than guessing its time-to-live or applying funny heuristics, the browser deletes it when it shuts down.
• Persistent cookies: A persistent cookie, on the contrary, is stored on the client until the deadline set by its Expires or Max-Age directives.
• Session restoring: It is worth noting that browsers might employ a mechanism known as session restoring, where session cookies can be recovered after the client shuts down. There’s nothing the server could do about it.

Host-only

• When a server does not include a Domain directive the cookie is to be considered host-only, meaning that its validity is restricted to the current domain only and subdomains have no access to it.
• If we set Domain=some.domain then all subdomains say sub.some.domain will have access to it.

Supercookies

• TLD-cookies, otherwise known as supercookies, are disabled by web browsers for user privacy and prevent information leakage.

• permacookies (permanent cookies) or zombiecookies (cookies that never die).

• ETag tracking is used for tracking instead of supercookies.

Cookie Flags

• Secure: send and recive cookie only when connection is https. Security from MITM Attack.
• HttpOnly: JavaScript Can't Touch This ie document.cookie.
  • By using this directive we can instruct the browser not to share the cookie with JavaScript. The browser then removes the cookie from the window.cookie variable, making it impossible to access the cookie via JS.
  • Helps in mitigating xss attack.
• SameSite: The CSRF Killer. This flag effectively eliminates Cross-Site Request Forgery (CSRF) from the web.
  • When you tag a cookie with this flag, you tell the browser not to include the cookie in requests that were generated by different origins.
  • It has 3 variants: Lax, Strict, None By default it's Lax which is set by browser itself. More here

Alternatives to Cookies

• LocalStorage: The problem with this approach, though, is that localStorage does not offer any kind of protection against XSS attacks. If an attacker is able to execute a simple localStorage.getItem('token') on a victim’s browser, it’s game over. HttpOnly cookies easily overcome this issue.

---

Scenarios

Session Invalidation in a stateless architecture

• using sessonIDs to maintain session that requires you to check sessionID match in db to with that of sent via browser is called statefull.
• Using JWT without storing it in db as many do makes it stateless as http is a stateless protocol in itself
• This creates a problem as when you logout you delete the jwt but it's not invalidated if it's stolen by someone
• Best is to use a mix of these two or perhaps jwt as stateful so you can provide features like multiple device login and logout to your users and it more secure but this costs you a call to db everytime you gets a request, maybe caching is the way.
• There also exists two token method that uses a short lived token and a long lived token yet it doesn't solve the problems fully but it saves some db calls for token verification based on short lived token ttl.

CDN Compromise

• If your CDN account get's compromised than an attacker could change your js files that are being served. To prevent anything wrong from happening further always have integrity checks in you html file where you are loading the file from cdn as that would not let that file to execute anycode if it's integrity check fails.

<script 
  src="https://my.cdn.com/asset.js" 
  integrity_no="sha256-Y34u3VVVcO2pZtmdTnfZ+7OquEpJj/VawhuWPB4Fwq3ftcFc0gceft1HNZ14eUHT"
></script>

• cat $ASSET_FILE_NAME | openssl dgst -sha384 -binary | openssl base64 -A

EV Certs

• Extended Validation certificates are dead.

Scenarious

CORS

• Imagine if an attacker would set up a malicious page at win-a-hummer.com that immediately triggers an AJAX request to your-bank.com. If you’re logged in on the bank’s website, the attacker would then be able to execute HTTP requests with your credentials, potentially stealing your information or, worse, wiping your bank account out.
• When making a get request, an important aspect we need to understand is that the browser executed the request but prevented the client from accessing it when using cors-header. This is extremely important, as it still leaves us vulnerable if our request would have triggered any side effect on the server. Imagine, for example, if our bank would allow us to transfer money by simply calling the url my-bank.com/transfer?amount=1000&from=me&to=attacker, that would be a disaster!
• As we saw at the beginning of this chapter, GET requests are supposed to be idempotent
• Instead of directly executing our POST request, which could potentially cause some serious trouble on the server, the browser sent a preflight request. This is nothing but an OPTIONS request to the server, asking it to validate whether our origin is allowed. In this case, the server did not respond positively, so the browser stops the process, and our POST request never reaches the target.
• CORS is not a simple specification. There are quite a few scenarios to keep in mind and you can easily get tangled in the nuances of features such as preflight requests.
• Never expose APIs that change state via GET. An attacker can trigger those requests without a preflight request, meaning there’s no protection at all.
• Someone said: I found myself more comfortable with setting up proxies that can forward the request to the correct server, on the backend rather than using CORS. This means that your application running at example.com can set up a proxy at example.com/_proxy/other.com, so that all requests falling under _proxy/other.com/* get proxied to other.com.

Origin vs Referrer

• The Origin header is very similar to Referrer, as it’s sent by the browser in cross-domain requests to make sure the caller is allowed to access a resource on a different domain. The Origin header is controlled by the browser, so there’s no way malicious users can tamper with it. You might be tempted to use it as a firewall for your web application. If the Origin is in our whitelist, it lets the request go through.

• One thing to consider is that other HTTP clients such as cURL can present their own origin. A simple curl -H "Origin: example.com" api.example.com will render all origin-based firewall rules inefficient. That is why you cannot rely on the Origin (or the Referrer, as we’ve just seen) to build a firewall to keep malicious clients away.

Security.txt

Contact: mailto:[email protected]
Preferred-Languages: en
Canonical: https://example.com/security.txt
Policy: https://example.com/bug-bounty-program.html
Hiring: https://example.com/careers.html
Acknowledgments: https://example.com/hall-of-fame.html

example fb: https://www.facebook.com/security.txt