Some common web security topics and patterns.

Crypto-miner

Cryptocurrency mining, or cryptomining, is a process in which transactions for various forms of cryptocurrency are verified and added to the blockchain digital ledger. Also known as cryptocoin mining, altcoin mining, or Bitcoin mining (for the most popular form of cryptocurrency, Bitcoin), cryptocurrency mining has increased both as a topic and activity as cryptocurrency usage itself has grown exponentially in the last few years.

Websites that run javascript on your browser to do some processing to mine bitcoins. These are coin-hives. There were attacks where the attacker was able to inject their js into a commonly shared library. Every website that used that shared library now had a coinhive js being injected. That js was running on the browser to do crypto-mining.

Subresource Integrity (SRI)

Subresource Integrity (SRI) is a security feature that enables browsers to verify that resources they fetch (for example, from a CDN) are delivered without unexpected manipulation. It works by allowing you to provide a cryptographic hash that a fetched resource must match.

Using Content Delivery Networks (CDNs) to host files such as scripts and stylesheets that are shared among multiple sites can improve site performance and conserve bandwidth. However, using CDNs also comes with a risk, in that if an attacker gains control of a CDN, the attacker can inject arbitrary malicious content into files on the CDN (or replace the files completely) and thus can also potentially attack all sites that fetch files from that CDN.

Subresource Integrity enables you to mitigate some risks of attacks such as this, by ensuring that the files your web application or web document fetches (from a CDN or anywhere) have been delivered without a third-party having injected any additional content into those files — and without any other changes of any kind at all having been made to those files.

<script src="https://example.com/example-framework.js"
        integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC"
        crossorigin="anonymous"></script>

If this check were to fail, the browser would throw an error like this:

Failed to find a valid digest in the 'integrity' attribute for resource 'http://staging.org.com/assets/vendor-0ada2c9fb4d3e07ad2f0c6a990945270.js' with computed SHA-256 integrity 'Sb4Xc/Oub27QW0MKlqK0sbq0Mm476jU7MgJaCzd/gKk='. The resource has been blocked

You can generate SRI hashes from the command-line with openssl using a command invocation such as this:

cat FILENAME.js | openssl dgst -sha384 -binary | openssl base64 -A

or with shasum using a command invocation such as this:

shasum -b -a 384 FILENAME.js | awk '{ print $1 }' | xxd -r -p | base64

Content Security Policies (CSP)

Content Security Policy (CSP) is an added layer of security that helps to detect and mitigate certain types of attacks, including Cross Site Scripting (XSS) and data injection attacks. These attacks are used for everything from data theft to site defacement to distribution of malware.

CSP is designed to be fully backward compatible (except CSP version 2 where there are some explicitly-mentioned inconsistencies in backward compatibility; more details here section 1.1). Browsers that don’t support it still work with servers that implement it, and vice-versa: browsers that don’t support CSP simply ignore it, functioning as usual, defaulting to the standard same-origin policy for web content. If the site doesn’t offer the CSP header, browsers likewise use the standard same-origin policy.

To enable CSP, you need to configure your web server to return the Content-Security-Policy HTTP header. (Sometimes you may see mentions of the X-Content-Security-Policy header, but that’s an older version and you don’t need to specify it anymore.)

Alternatively, the <meta> element can be used to configure a policy, for example: <meta http-equiv="Content-Security-Policy" content="default-src 'self'; img-src https://*; child-src 'none';">

By default, violation reports aren’t sent. To enable violation reporting, you need to specify the report-uri policy directive, providing at least one URI to which to deliver the reports:

Content-Security-Policy: default-src 'self'; report-uri http://reportcollector.example.com/collector.cgi

Then you need to set up your server to receive the reports; it can store or process them in whatever manner you determine is appropriate.

SRI vs CSP

These two services are complimentary, one doesn’t really replace the other. SRI is checking if the file received is legit and the one we expected. CSP is saying here are all the sites I can get content from, no where else.

Cross Site Scripting (XSS)

Browsers have native defenses to prevent XSS. This can happen when script is added into the URL as a query string.

The HTTP X-XSS-Protection response header is a feature of Internet Explorer, Chrome and Safari that stops pages from loading when they detect reflected cross-site scripting (XSS) attacks. Although these protections are largely unnecessary in modern browsers when sites implement a strong Content-Security-Policy that disables the use of inline JavaScript ('unsafe-inline'), they can still provide protections for users of older web browsers that don’t yet support CSP.

X-XSS-Protection: 1; mode=block

header("X-XSS-Protection: 1; mode=block");

<IfModule mod_headers.c> 
  Header set X-XSS-Protection "1; mode=block" 
</IfModule>

add_header "X-XSS-Protection" "1; mode=block";

HTTP / HTTPS

Until recently, most browsers would show an icon or display saying “Secure” when going over HTTPS. However, it would not show anything when going over HTTP, which means the user needs to imply the site is not secure. Recently browsers have made it so that when on a site with form (entering data), then it will explicitly say “Not Secure”.

The reason the “Not Secure” only shows on forms is because when just displaying data its not considered a threat or risk of transmitting data insecurely. However, this is changing and most browsers now clearly mark HTTP sites as “Not Secure”.

In the past supporting HTTPS required payment through a CA. However, with the introduction of “Lets Encrypt”, cost is no longer a problem. Below are some other complaints for HTTP and the reasons against them.

https://doesmysiteneedhttps.com/

HTTP Public Key Pinning (HPKP)

HTTP Public Key Pinning (HPKP) was a security feature that used to tell a web client to associate a specific cryptographic public key with a certain web server to decrease the risk of MITM attacks with forged certificates. It has been removed in modern browsers and is no longer supported.

The way it works is that the server gives the browser a set of public keys. The browser will check the public keys to ensure one of them matches the certificate it’s using to access the site.

To ensure the authenticity of a server’s public key used in TLS sessions, this public key is wrapped into a X.509 certificate which is usually signed by a certificate authority (CA). Web clients such as browsers trust a lot of these CAs, which can all create certificates for arbitrary domain names. If an attacker is able to compromise a single CA, they can perform MITM attacks on various TLS connections. HPKP can circumvent this threat for the HTTPS protocol by telling the client which public key belongs to a certain web server.

https://caniuse.com/?search=hpkp

Certificate Transparency

Certificate Transparency is an open framework designed to protect against and monitor for certificate misissuances. Newly issued certificates are ‘logged’ to publicly run CT logs which maintain an append-only, cryptographically assured record of issued TLS certificates.

In this way, certificate authorities (CAs) can be subject to much greater public scrutiny and oversight. Potentially malicious certificates, such as those that violate the CA/B Forum Baseline Requirements, can be detected and revoked much more quickly. Browser vendors are also empowered to make more informed decisions regarding problematic CAs that they may decide to distrust.

Certificate Authority Authorization CAA

DNS Certification Authority Authorization (CAA) is an Internet security policy mechanism which allows domain name holders to indicate to certificate authorities whether they are authorized to issue digital certificates for a particular domain name. It does this by means of a new “CAA” Domain Name System (DNS) resource record.

It was drafted by computer scientists Phillip Hallam-Baker and Rob Stradling in response to increasing concerns about the security of publicly trusted certificate authorities. It is an Internet Engineering Task Force (IETF) proposed standard.

CAA is a security measure that allows domain owners to specify in their Domain Name Servers (DNS) which CAs are authorized to issue certificates for that domain. If a CA receives an order for a certificate for a domain with a CAA record and that CA isn’t listed as an authorized issuer, they are prohibited from issuing the certificate to that domain or any subdomain.

Use SSL Labs to analyze a site’s SSL certifcate.
https://www.ssllabs.com/ssltest/

Cross Origin Resource Sharing (CORS)

Cross-Origin Resource Sharing (CORS) is an HTTP-header based mechanism that allows a server to indicate any other origins (domain, protocol, or port) than its own from which a browser should permit loading of resources. CORS also relies on a mechanism by which browsers make a “preflight” request to the server hosting the cross-origin resource, in order to check that the server will permit the actual request. In that preflight, the browser sends headers that indicate the HTTP method and headers that will be used in the actual request.

An example of a cross-origin request: the front-end JavaScript code served from https://domain-a.com uses XMLHttpRequest to make a request for https://domain-b.com/data.json.

For security reasons, browsers restrict cross-origin HTTP requests initiated from scripts. For example, XMLHttpRequest and the Fetch API follow the same-origin policy. This means that a web application using those APIs can only request resources from the same origin the application was loaded from unless the response from other origins includes the right CORS headers.

Contact Details

For public facing sites, you should remember to put contact details. This can be useful when security inspectors find issues or vulnerabilities. This can be done by using a security.txt.
https://securitytxt.org/

References

Have I been PWND
https://haveibeenpwned.com/

Does my site need HTTPS
https://doesmysiteneedhttps.com/

Can I use (browser support)
https://caniuse.com

DNS Spy
https://dnsspy.io/

Qualys SSL Test
https://www.ssllabs.com/ssltest/

Security TXT
https://securitytxt.org/

eof