Posts Tagged ‘http’

OVH et les headers HTTP

Friday, January 15th, 2016

Si un soir d’hiver, il vous prend l’envie d’envoyer des headers HTTP à votre back-end hébergé chez OVH (i.e., si vous êtes aussi cinglés que moi), alors ma petite histoire devrait vous intéresser (en tout cas la conclusion)!

Comme j’ai une forte tendance à vouloir expérimenter, j’ai mis en place un petit système de jetons basés sur les JSON Web Tokens (JWT), de façon à pouvoir en générer à la volée, vérifier leur validité, les renouveler, etc.

Comme je n’ai toujours pas de serveur dédié (à vot’ bon coeur :p), j’ai implémenté ça en PHP (cfr mon post précédent) et j’ai uploadé ça sur un hébergement OVH.

J’avais évidemment tout développé/testé en local et j’étais plutôt content de moi. Or voilà, une fois déployé sur OVH, mon premier essai a été un échec total. Tellement foireux même que j’ai crû à une éclipse lunaire.

Après avoir retourné le bouzin pendant une bonne demi heure, je viens de me rendre compte qu’OVH ne passe pas les headers HTTP sans les chatouiller un peu au passage.

En effet, mon joli header “Authorization” disparaît pûrement et simplement à l’arrivée, tandis qu’une version plus exotique telle que “X-Authorization” devient quand à elle “X_Authorization”.

Alors je m’imagine bien qu’OVH fait ça pour de super bonnes raisons (que je suis curieux de découvrir), mais j’avoue que pour le coup ils ont réussi à me donner la nausée :)

Bref, vous êtes prévenus!


Security HTTP Headers FTW

Saturday, December 19th, 2015

In the last couple of months, I’ve tried to improve the overall security of this site. I’ve started by putting my server behind Cloudflare to get HTTPS (along with other nice availability/performance improvements). Then I closed my eyes and enabled HSTS. I even dared adding this site to the HSTS preload list (i.e., the list of HSTS-enabled websites loaded in all modern browsers). Weakest-Link-Graphic Today I’m taking this a step further with the addition of some security-related HTTP headers. You might say that this was the very first thing I should’ve done and you’d be right to say so, but here comes :) From now on, if you take a look at the initial response, you’ll see that the following headers (among others) are being sent to you:

...
X-Frame-Options "SAMEORIGIN"
X-Xss-Protection "1; mode=block"
X-Content-Type-Options "nosniff"
content-security-policy: "default-src 'self'; style-src 'self' 'unsafe-inline' https://fonts.googleapis.com; img-src * data:; script-src 'self' 'unsafe-inline' https://ajax.googleapis.com https://apis.google.com https://*.linkedin.com https://platform.twitter.com https://connect.facebook.net;child-src 'self' https://accounts.google.com https://apis.google.com https://platform.twitter.com https://*.facebook.com; font-src 'self' https://fonts.gstatic.com data:; frame-ancestors 'none';report-uri https://www.dsebastien.net/csp_report.php; connect-src 'self'; form-action 'self'; upgrade-insecure-requests; reflected-xss block; base-uri https://www.dsebastien.net; object-src 'none'"

The X-* headers give additional protection against clickjacking, cross-site scripting (XSS) and preventing some user agents from doing mime type sniffing. Those are nice, but the main one is the Content Security Policy (CSP). There are tons of articles about what a CSP is and how to configure one so I won’t go into the details of that. Any security expert will quickly notice that this isn’t the strictest CSP (far from it) because it allows ‘unsafe-inline’ for scripts & styles. The thing is that adding hashes or nonces to all scripts and styles is not an easy thing to do; even less so when you inherit that from many wordpress plugins… Also, some minified code (e.g., jQuery plugins) uses eval (evil?). For now, I’ve decided to lower my security goal. I’ll surely revisit this later though (probably with the new version of the site). Notice that the CSP makes some older HTTP headers redundant (e.g., X-Frame-Options) but I’m still keeping the older variants just for the sake of wider support. These will go away over time. Here are some tips if you want to go about and create a CSP for your site/domain:

  • start with the report-only mode. It’ll only log errors in the console and will not actually block anything; this is a great starting point:
    content-security-policy-report-only: default-src 'none';
  • use tools such as the CSP extension for Fiddler or an online CSP generator
  • once you’ve got rid of all console errors, remove ‘report-only’ to make your CSP effective
  • configure a ‘report-uri’ to be aware of CSP-related issues. Just be careful with this as attackers might probably take advantage of that (i.e., do not mail yourself all violations :p)

More generally, you can use online tools such as this one to review your site’s security headers. If you look at my site there, you’ll see that I could add HTTP Public Key Pinning (HPKP) headers to improve security a bit more. I won’t do it though as I don’t want my site to break whenever CloudFlare decides to present a new certificate in front of my site…

As a side note, if you’re using Apache, you can configure security headers through .htaccess files and the headers module (mod_headers). Here’s an example:


Header always set X-Frame-Options "SAMEORIGIN"
...

I’m sure that this site still has many vulnerabilities, but there aren’t enough hours in the day for me to fix everything at once. I have other improvements in mind, but that’ll be for later! :)