Written on 13 February 2018, 09:10pm

Tagged with: , , ,

Content Security Policy (CSP)

The modern browsers are able to interpret the Content-Security-Policy HTTP header that defines which dynamic assets are allowed to load on a given website. Alternatively, the CSP content can be sent using meta HTML tags.


// allow everything but only from the same origin:
default-src 'self'; 
// allow JS but only from example.eu and from the same origin:
script-src 'self' https://example.eu/myapp; 
// allow XMLHttpRequests but only from example.eu and the same origin:
connect-src 'self' https://example.eu/myapp; 

You can find all the possible directives here and a tool that can generate your CSP header here.

The amazing thing about CSP is the Report-URI attribute, which will report the deviations from the policy to the specified URL:

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

One of the services collecting such reports is report-uri.com.

Subresource_Integrity (SRI)

SRI is a very simple and effective concept: the modern browsers load a given asset only if its hash matches the one defined in the ‘integrity’ attribute.

So instead of doing this:

<script src="//www.example.com/script.js" type="text/javascript"></script>;

it’s recommended to do this:

<script src="//www.example.com/script.js" type="text/javascript"

or even better, link each version of the remote asset with its own URL and hash:

<script src="//www.example.com/1.0.1/script.js" type="text/javascript"

Cross-Origin Resource Sharing (CORS)

– a script on client.com wants to access some data from server.com (ex. XMLHttpRequest)
– by default, the same-origin browser policy blocks this request

– but by adding some special response headers, server.com can allow the script client.com to access the data.

The modern browsers have implemented a mechanism allowing scripts (like XMLHTTPRequest) to make cross-domain requests. This is Cross-Origin Resource Sharing and it uses a relatively less used HTTP request method (OPTIONS) plus several response headers (Access-Control-Request-Method, Access-Control-Request-Headers, etc)

Resources from Mozilla Development Network (MDN):

Glossary: CSP, SRI, CORS

Technical details: CSP, SRI, CORS


Over the weekend, hackers injected thousands of websites—including UK and US government sites—with code that hijacked visitors’ computers to mine cryptocurrency.

The attack, noticed on Sunday by security researcher Scott Helme, was pulled off by compromising a single plugin that was used by all of the affected sites: Browsealoud, a reputable suite of accessibility and translation tools. According to Helme, the plugin was edited by attackers to embed a script that uses a site visitor’s computer to do the complex math that generates new digital coins (in this case, Monero). This process, known as “mining,” can slow down the victim’s computer.

The attack loaded malicious Javascript onto visitors’ computers. The hackers behind the attack chose to mine cryptocurrency, but they had the power to do almost whatever they wanted.
Cryptocurrency Mining Hack That Compromised Thousands of Sites ‘Could Have Been a Catastrophe’

Scott Helme: Protect your site from Cryptojacking with CSP + SRI
Troy Hunt: Trust in Third Party Libraries

State and the web

Written on 26 February 2017, 06:26pm

Tagged with: , , ,

How do you get around the stateless nature of the web?

The HTTP protocol (along with other building blocks of the web, like IP and HTML) is stateless by design. This means that each connection is made up of a request and response, without any reference to earlier/later connections. “Users don’t log in to the Web, nor do they ever log out”. So without any intervention, each connection to a website (each page visit) is independent from the others.

How do you get around that?
Well, 3 possibilities, all of them using existing elements of the HTTP protocol:
1. HTTP Headers: cookies
2. HTTP URL: query string parameters
3. HTTP Body: POST (form) data
Important to note is that each of these can be altered (spoofed) by the client.

HTTP/2 is still stateless, but has some stateful components

HTTPS is stateless as well. Just because there is a TLS handshake at the beginning does not make the connection stateful. The stateful protocol is TLS, but HTTPS remains stateless, just as HTTP.

Example of a stateful protocol: FTP. “FTP has a stateful control connection which maintains a current working directory and other flags, and each transfer requires a secondary connection through which the data are transferred” (wikipedia)

Summing up:
Stateless: HTTP, HTTPS, IP
Stateful: TCP, TLS, FTP


How to send data from server to client over the web

1: Long polling the client polls the server; the server holds the request open until new data is available. Then the server responds and sends the new information. When the client receives the new information, it immediately sends another request.
2: Server Push – available in HTTP/2: client requests index.html, server responds with index.html but also with style.css and script.js, before the client parses index.html and asks for them
3. WebSockets (ws:// and wss://) – are a HTML5 feature aimed to address the request/response architecture of the web. There is an persistent connection between the client and the server and both parties can start sending data at any time.

Related links:

What really happens when you navigate to a URL
Understanding the concepts of Transport Security Layer (TLS)
How HTTP/2 will speed up your web browsing
XKCD: Server Attention Span
ColdFusion Book
An Introduction to WebSockets

Currently, HTTP servers respond to each client request without relating that request to previous or subsequent requests; the state management mechanism allows clients and servers that wish to exchange state information to place HTTP requests and responses within a larger context, which we term a “session”. This context might be used to create, for example, a “shopping cart”, in which user selections can be aggregated before purchase, or a magazine browsing system, in which a user’s previous reading affects which offerings are presented.

Neither clients nor servers are required to support cookies. A server MAY refuse to provide content to a client that does not return the cookies it sends.

The website is down

Written on 6 December 2014, 12:02pm

Tagged with: , , ,

From a business perspective:

– 1. Think Ahead and Anticipate
– 2. Say Something
– 3. Know the Law
– 4. Remember, You’re Not Alone
What to Do When Your Website Gets Hacked

From a technical perspective:

1. Check That It Has Actually Gone Down
2. Figure Out What Has Gone Down
3. How Bad Is It?
4. Check Your Web Server Software
5. Logging Into Your Server
6. Has It Run Out Of Space?
7. Has It Run Out Of Memory?
8. Has Something Crashed?
What To Do When Your Website Goes Down

And remember, don’t just stand there, reboot something 🙂

From a fun perspective:

Bonus: What Flickr did when their website went down:

AARRON WALTER: Designing for emotion
In July 2006, a storage failure struck Flickr, the popular photo sharing service. Though photos were safe and no data was lost, thousands of enthusiastic users were inconvenienced as
their favorite photo site took a temporary nap (roughly three hours). Tensions ran high as engineers worked to bring the site back online. Inquiries from concerned users poured in.
During the crisis, the Flickr team had a stroke of genius.
[..] They posted a message that explained the outage, asked users to print a page, and do something creative with it to win a free, one-year Flickr Pro account:

flickr 404