24 Feb 2016, 09:30

Around the Web - February 2016 - MySQL, Docker, Security & Webapps/API



  • Official images are to move from Ubuntu to Alpine : main arguements are about disk space saving (and so bandwith and time to launch a container) and security (lower surface of attack).
    • "Alpine Linux is a security-oriented, lightweight Linux distribution based on musl libc and busybox" according to the site
    • First, I was sceptical as it requires the whole ecosystem to move from ubuntu to alpine ; indeed, wether you like it or not, people are used to ubuntu/debian and other mainstream distribution and all packages we are used to have are not yet available in alpinelinux also. To be honest, main packages are available.
    • Then, a debian or whatever base image will still exist, be safe with that ; however, if you want to "hack" / inherit from a docker base image, you'll have to switch to Alpine.
    • Third, we could consider that once your docker host has the base image in cache, the ~180M size of base image is not an issue. But starting from 5M may be a good argument however.
    • Starting testing it on ARM device and especially Raspberry Pi, I'm quite pleased with its reactivity and packages available.
  • Some tips to reduce the size of your docker image and also understand how size and layers impacts your docker image. Following the instructions, I could reduce my influxdb-chronograf docker image by 70M approx (from 360 to 290M if I'm correct)

Security & API/Web App


26 Nov 2014, 09:30

Around the Web - November 2014




HTML5/CSS/Responsive Web Design

  • 7 CSS Units you may not know about : rem, vh, vm, vmin, vmax, ex and ch. I did not know the two latter. Some more examples for the vh/vm and vmin/vmax.
  • About rem and em more specially, if you want to move from a fixed approach (ie pixel one) to a more fluid/adaptive one (em/rem), you should read this article  and then this one which explain the issue with pixels and the new way to manage it. You can also use em/rem for positionning content ; em/rem are not only about text.
  • 5 obsolete features in HTML5: hgroups tag, pubdate and scope attributes, command and center elements. With the good way to implement them and/or some workaround if you still need them.
  • RWD adoption 2014 : top 100/1000/10.000 sites are evaluated - from to what extend is RWD implemented to mobile site vs RWD benchmarks in terms of performance.
  • 6 technologies that will change the web platform : asm.js, paralleljs, ECMAScript 6, web components, installable webapps, CSS Grid layout
  • The state of Web Animation 2014 : Between the post-Flash area and the Web Animation API to be implemented in all browsers, a review of current challenges and polyfill to bring animations into the browsers. Comments are also worth to read to get more resources.
  • If you are interested in a book about RWD, seems the latest book from A book apart may interested you : Responsible responsive web design (related review)


Web Performance

  • M6 Tech team made a review of their participation to Velocity conf (day 1, day 2, day 3), a web performance oriented conference. Even if their synthesis is in French, related slides and video are in English. You can also find the one of 2013 (day 1, day 2, day 3)


React (Facebook)

  • React through the ages : an interesting introduction (from origin to what's coming) about React, a JS library to build user interfaces.

12 Nov 2014, 11:15

HTTPS Certificates : some changes in the coming months

When you issue a certificate, there are some encryption mechanism under the hood. One of them is "SHA-1" and it has been declared as weak some months ago.

As a consequence :

  • Certificates should be issued using SHA-2 encryption mechanism instead of SHA-1
  • Main browsers are to drop progressively the support of SHA-1 certificates by lowering their level of security til they consider it as untrusted.
  • There are some incompatibility issues, mainly with Windows XP which does not support SHA-2 ; so as Microsoft no longer supports Windows XP and unless your are in China, you should be safe :-)

You can test your certificate for ex with SSL Labs or Shaaaaaaaaaaaa (a dedicated site on the topic).

So the action plan could be :

  1. Test your site to check if you use SHA-A1 certificates or not
  2. Depending on your audience, define a migration strategy depending on
    1. The expiration date for your certificates ; it may change the behavior on browsers side ; more details on Chrome/Firefox timeline mentioned above
    2. The browser's roadmap
  3. Don't forget to update the whole certificate chain ie get your new SHA-2 signed certificates but also the intermediary and root certificates from your certification authority. You can mix both (SHA-2 certificate with SHA-1 authorities certificates) but it's better to have a full SHA-2 certificate chain.
  4. Migrate to SHA-2

23 Apr 2014, 09:30

Web Roundup - 23/4

This blog is not (yet) dead ; some links :

  • Internet Explorer Web Platform Status and Roadmap : To know if/when some features of HTML5/CSS3/JS have been implemented in Internet Explorer from IE9 to "Under Consideration" or "Not currently planned"
  • If you want to build Windows 8 apps in JS (instead of .net technologies) but also more general UI in HTML/CSS/JS (more sceptical on this one), you may be interested by WinJS, recently opensourced by Microsoft. You can even try it first and then look at the code/project.
  • HTML5 Security Cheat sheet : some security points to have in mind
  • WTF, HTML and CSS? : Reasons HTML and CSS might make you say what the fuck. A curated list of commonly frustrating HTML and CSS quandaries, miscues, and dilemmas.
  • A "Should I use" in French about some ergonomic pitfalls like caroussel, intrusive pop-in, fixed headers/footers, etc with samples. Still work in progress but with some good examples.

Till next time !

26 Jun 2013, 23:24

Content Security Policy (CSP)

On a similar topic as CORS and the same origin police I wrote some months ago, there is another initiative called Content Security Policy which is defined as follow in the Mozilla Developper Network CSP Page :

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 or distribution of malware.


The idea behind is that you will "whitelist" the code you accept to render whether it is hosted on third party serivces (like facebook or google buttons) up to inline code within your page (yes, I mean the CSS and JS code you add with the <style> and <script> tags)

What does it look like ?

It's so far only a HTTP Header called "Content-Security-Policy" you will have to set ; for the 1.1 Specs, it will also be a "meta" tags you can set in your HTML.

You will define then the diffrent directives you want to have, depending on your needs :

  • connect-src limits the origins to which you can connect (via XHR, WebSockets, and EventSource).
  • font-src specifies the origins that can serve web fonts. Google’s Web Fonts could be enabled via font-src https://themes.googleusercontent.com
  • frame-src lists the origins that can be embedded as frames. For example: frame-src https://youtube.com would enable embedding YouTube videos, but no other origins.
  • img-src defines the origins from which images can be loaded.
  • media-src restricts the origins allowed to deliver video and audio.
  • object-src allows control over Flash and other plugins.
  • script-src lists the origin of scripts that would be loaded
  • style-src is script-src’s counterpart for stylesheets.

Let's see an example :

Content-Security-Policy: script-src 'self' https://apis.google.com

It would mean that :

  • any script loaded from my domain and from https://apis.google.com will be loaded.
  • If you try to load jquery from code.jquery.com in your html, it will not be loaded as this host has not been whitelisted.

Another example to illustrate to what extend you can fine tune this directive :

Content-Security-Policy: default-src 'none'; script-src https://cdn.mybank.net; style-src https://cdn.mybank.net; img-src https://cdn.mybank.net; connect-src https://api.mybank.com; frame-src 'self'

It would mean that :

  • You will not load any code hosted on your domain
  • Script, Style and Image files can only be loaded fomr https://cdn.mybank.net
  • You can connect via Ajax or similar only to https://api.mybank.com/
  • and load frame only from your domain
  • Outside of this rules, all other code/content will never be loaded.

Last one, if you want your site to load all the required files for social widgets (like Facebook, Twiitter, Google ones), the directive would be :

Content-Security-Policy: default-src 'self'; script-src https://apis.google.com https://platform.twitter.com; frame-src https://plusone.google.com https://facebook.com https://platform.twitter.com

Inline CSS / JS Code

Sometime you do have some Javascript / CSS code in your html. Even if you defined "self" as default-src, it will prevent from loading indline JS/CSS code and also prevent "eval()" to be computed.

So the best practice is of course to put your CSS / JS code in external files. However, if you can't, you will have to add the "unsafe-inline" and "unsafe-eval" directives. Of course, it's strongly disrecommended. Indeed, if anyone can inject code in your page, then it will do whatever he wants.

Reporting & Monitoring

Introducing CSP may hurt your site to some extend  as you may forgot to declare some required resources and of course you may be interested to know if someone tries to inject code. CSP also provides some directives for these two needs.

First, for debug purposes, you have the "report-only" directive that would report files to be excluded but will not block them ; you will then use :

Content-Security-Policy-Report-Only: default-src 'self'; ...; report-uri /my_amazing_csp_report_parser;

Once you are fine and go in production, you want to know what happens in reality and prevent malicious code to be loaded. Just do as follow :

Content-Security-Policy: default-src 'self'; ...; report-uri /my_amazing_csp_report_parser;

For both cases, once the rule is hit, the browser will POST the information to your report uri and you will have something like :

  "csp-report": {
    "document-uri": "http://example.org/page.html",
    "referrer": "http://evil.example.com/",
    "blocked-uri": "http://evil.example.com/evil.js",
    "violated-directive": "script-src 'self' https://apis.google.com",
    "original-policy": "script-src 'self' https://apis.google.com; report-uri http://example.org/my_amazing_csp_report_parser"

Current support in browsers

  • Firefox from Firefox 23 (next stable release) and later. Firefox for Android and Firefox OS soon to follow.
  • Chrome :  25 and later
  • Internet Explorer : 10 and later (sandbox directive only)

How if differs from CORS ?

CORS also aims to mitigate the "same origin policy" issue by allowing which sites can load your content. CSP is the opposite as you would define which hosts you want to load content from and will go deeper as it allows a fine grained control on the loaded/computed code.

I would say CSP it really security focused whereas CORS was more to ease developper tasks to load content from another place.

More resources on CSP

[Edit 1] : An example on how to play safely in sanboxed iframes.

05 Apr 2013, 22:27

Postgres > Major security issue > PostgreSQL 9.2.4, 9.1.9, 9.0.13 and 8.4.17 released

For those using Postgres, a minor release was made yesterday fixing some major security issues ; everyone is strongly recommended to upgrade its postgres server immediatly ; especially if your server is accessible from outside of your network ; if you are hosted internally, it's safe to upgrade but not as urgent.

Quoting the announce :

A major security issue fixed in this release, CVE-2013-1899, makes it possible for a connection request containing a database name that begins with "-" to be crafted that can damage or destroy files within a server's data directory. Anyone with access to the port the PostgreSQL server listens on can initiate this request. This issue was discovered by Mitsumasa Kondo and Kyotaro Horiguchi of NTT Open Source Software Center.

Two lesser security fixes are also included in this release: CVE-2013-1900, wherein random numbers generated by contrib/pgcrypto functions may be easy for another database user to guess, and CVE-2013-1901, which mistakenly allows an unprivileged user to run commands that could interfere with in-progress backups. Finally, this release fixes two security issues with the graphical installers for Linux and Mac OS X: insecure passing of superuser passwords to a script, CVE-2013-1903 and the use of predictable filenames in /tmp CVE-2013-1902. Marko Kreen, Noah Misch and Stefan Kaltenbrunner reported these issues, respectively.

I will also remember that the 8.3 version of Postgres is no longer maintained nor supported from end February 2013 and current 8.4 is maintained/supported up to July 2014. More information on the Versioning policy page.

Source :

03 Apr 2013, 22:22

Web Roundup - 3/4

Below some links I found useful / relevant / interesting to share :

26 Feb 2013, 21:51

Browser : Same Origin Policy & CORS

The same origin policy for Javascript is defined as follow :

The same-origin policy restricts how a document or script loaded from one origin can interact with a resource from another origin.

And regarding "origin" : Two pages have the same origin if the protocol, port (if one is specified), and host are the same for both pages. The following table gives examples of origin comparisons to the URL http://store.company.com/dir/page.html:

https://store.company.com/secure.htmlFailureDifferent protocol
http://store.company.com:81/dir/etc.htmlFailureDifferent port
http://news.company.com/dir/other.htmlFailureDifferent host

For security reason, it's obvious to understand that it's not allowed. However, sometimes you may need to interact with data hosted elsewhere in the browser :

  • Display a menu hosted elsewhere (as we do for Globe where the menu is hosted on CMS side but also displayed on DMS side)
  • You may want to aggregate several RSS Feeds coming from different services in a single page, by using some ajax code
  • ...

You can do it by embedding some content from a given domain into another one (like image, video, some scripts, etc) but as soon as you have ajax/ XmlHttpRequest, you are in the same origin policy and you are blocked, till you discover CORS (Cross Origin Ressource Sharing) which provides a way for web servers to support cross-site access controls, which enable secure cross-site data transfers. You can use CORS for :

If from a DomaineA.com you need to fetch data from DomaineB.com, you will then need :

  • On DomaineB.com to add some Access-Control-* headers in your page to define who can safely pull your data
    • Access-Control-Allow-Origin : authorised hosts list or * if you authorise all hosts.
    • Access-Control-Request-Method : Get / Put / Post / Delete
    • Access-Control-Request-Headers : if you want to check against given headers
    • Access-Control-Allow-Credentials : if you want credentials to access your data
    • ...
  • If you don't do this, no way to fetch data from DomaineB.com - your browser will block you when you are on domaineA.com.

Once you enabled cors on client/server side, you can then safely fetch data from domaineB.com in your page hosted in domaineA.com ; nice isn't it ?

The main limitation for me so far is that you can use CORS only if you manage DomaineB server or have contact with domaineB owner, otherwise, you cannot do anything as you will not be granted to fetch data from their servers. Thus alternatives are :

  • Use a reverse proxy on domaineA.com to make the remote resource being seen as a local one to bypass same origin policy and not requiring CORS being enabled (I just did that for a pet project)
  • Go back to a initial backend treatment which will fetch the remote data to alllow you to consume it locally
  • Bypass it with other techniques your favourite language may provide

So even if CORS is a nice idea and a W3C recommendation, seems not mature enough and/or too much complex (unless you can manage the whole chain) to be used effectively on a public side. However for internal projects, it can make sense.

19 Feb 2013, 21:21

SQL Filter bypass

A series of (interesting) articles on SQL injection on how to bypass filters :

$Even if most of the cases are available for MySQL and in a PHP context, you may be interesting to have a look at some examples to rethink about the way you do your sql queries based on what you get from your app or the user (via forms or manual url guessing)

15 Jan 2013, 08:35

PHP 5.2 / 5.3 / 5.4

I read a reminder on the PHP support policy last week and thought it could be worth a reminder here :

  • PHP 5.2 version are no longer supported since 2 years with the release of PHP 5.2.16 on mid dec 2010 and the PHP Team to announce the end of support of PHP 5.2.x (even if PHP 5.2.17 was released in january 2011 ) It's time to consider upgrading to PHP 5.4 as soon as possible.
  • First version of PHP 5.4 was released in March 2012 and we are now on PHP 5.4.10 (released end decembre 2012)
  • I would not recommend using PHP 5.3 as first version is from end June 2009 and currently PHP 5.3.20 and most of all, PHP 5.3 support may be dropped with the coming release of PHP 5.5 (currently on alpha2 stage)

So the good resolution for 2013 is to use PHP 5.4 and nothing else, some guide to migrate :

Some may say that :

  • Their favorite OS does not provide the 5.4.x version by default - you may find them on community repositories for your favorite linux distribution and for Windows (but who does PHP on windows ?), php.net provide windows binaries.
  • Their favorie PHP libraries / CMS / ... does not support PHP 5.4 yet - it's time to pressure them or would be the only exception to stick with PHP 5.3 til PHP 5.4 is supported.

Nevertheless, a few community repositories I can recommend for gerting PHP 5.4 :

  • CentOS/RedHat/Fedora : Remi's RPMs - for Fedora, depending on the version you use, it may be already up to date.
  • Debian: DotDeb.org

[Edit 1] : Regading PHP 5.3 End Of Life, looks it would be security fixes ony (so no bug fix nor evolution) for one year once PHP 5.5 is released.

[Edit 2] : Here we are : PHP 5.5 is released (Changelog) and PHP 5.3 is no longer supported except for security bugs for 1 year.