Is CWE-525 still relevant?

During a code upgrade for a web application from Symfony 2.8 to 3.3 it also became time to do some basic tests with Zed Attack Proxy. While most findings were logical and easy to fix, but one was different and it started with the finding below.

Description:
The AUTOCOMPLETE attribute is not disabled on an HTML FORM/INPUT element containing password type input. Passwords may be stored in browsers and retrieved.
Solution:
Turn off the AUTOCOMPLETE attribute in forms or individual input elements containing password inputs by using AUTOCOMPLETE=’OFF’.

Included was the reference to CWE-525 that describes the risk and how to fix it. It leads back to the login section described in a Twig template file as below not having the proper attributes set on the form and/or input element.

<form class="navbar-form navbar-right" action="{{ path('login') }}" method="post">
    <div class="form-group">
        <input type="text" id="username" name="_username" placeholder="Email" class="form-control">
    </div>
    <div class="form-group">
        <input type="password" id="password" name="_password" placeholder="Password" class="form-control">
    </div>
    <button type="submit" class="btn btn-success">Sign in</button>
</form>

Mozilla Developer Network has an article about turning off form autocomplete for sensitive fields that browsers shouldn’t cache. Storing credit card data for example isn’t a good idea unless it is in a secured storage area. Updating the template file to contain right attributes and ZAP doesn’t complain anymore as we tell the browser not to store the password field.

<form class="navbar-form navbar-right" action="{{ path('login') }}" method="post">
    <div class="form-group">
        <input type="text" id="username" name="_username" placeholder="Email" class="form-control">
    </div>
    <div class="form-group">
        <input type="password" id="password" name="_password" placeholder="Password" class="form-control" autocomplete="off">
    </div>
    <button type="submit" class="btn btn-success">Sign in</button>
</form>

The story doesn’t end by adding the right attributes to resolve the finding, because browser makers have moved on as the attribute is being ignored for input elements of the type password for example. This as the benefit of having people store a secure password in password manager has a better risk score than people remembering and (re)using weak passwords. With this is mind we basically fixed a false positive to make the audit finding green.

For this reason, many modern browsers do not support autocomplete=”off” for login fields:

  • If a site sets autocomplete=”off” for a form, and the form includes username and password input fields, then the browser will still offer to remember this login, and if the user agrees, the browser will autofill those fields the next time the user visits the page.
  • If a site sets autocomplete=”off” for username and password input fields, then the browser will still offer to remember this login, and if the user agrees, the browser will autofill those fields the next time the user visits the page.

Here comes the problem as ZAP generates a finding that a developer has to spend time on as he needs to investigate and then has to implement a solution or explain why it isn’t worth fixing. Security scanners are handy for detecting low hanging fruit, but they shouldn’t become a time waster with outdated rules as developers will start ignoring findings or let findings slowly starve on their backlog.

Firefox 10 and bye bye Flash

Firefox 10 beta 6 was released on last week and with the final release coming soon it was time to have a closer look at Firefox 10. I must say that this is a release worth installing like Firefox 5 was with decent HTML5 video support. But what makes Firefox 10 different then previous releases? Then answer is simple, WebGL. WebGL is a way to do 3D programming and rendering directly from within JavaScript.

With Firefox 10 WebGL works and there for also Google Street View works without the need of Flash. Yes, another dependency on Flash has been removed. The previous major dependency was YouTube, but as some may have noticed they also are in a transition from Flash to HTML5 video where you get the HTML5 variant when Flash doesn’t work.

As more and more websites switch from a Flash-player for video toward HTML5 in under a year it makes you wonder what WebGL is going to change. Was HTML5 a year ago only for the geeks and cutting edge, now more and more starts to depend on it. With HTML5 Canvas a lot of Arcade games where rewritten to run in a webbrowser. With WebGL the question comes when Doom has been rewritten to run in a webbrowser. Maybe something for a Google Summer of Code project?

Te vaak verversen?

Webapplicaties wordt gemaakt op een desktop of op een server op hetzelfde netwerk en dan komen problemen niet snel naar boven. Behalve dat het wat langzamer wordt als je veel gebruikers hebt of veel data hebt, maar sommige developers verzoeken de goden. Het volgende is leuk als je de enige gebruiker bent en de server direct om de hoek staat, maar een refresh in JavaScript schrijven met een interval van 10 seconden is niet de meest ideale oplossing.

var date = new Date();
var ts = Math.round(date.getTime() / 1000);
if (ts - last_scheduled_update > 10 || _force_scheduled_update) {

De logfile van de webserver groeide dus snel, want elke webbrowser die deze applicatie draaide deed een POST bij de webserver om de laatste updates te verzamelen. Voorlopig is deze waarde naar 60 seconden verhoogd in de code en veel gebruikers merken er weinig van. Mogelijk dat de waarde zelfs naar 300 seconden kan wat voor veel webmail applicaties ook een acceptabele waarde lijkt te zijn.

var date = new Date();
var ts = Math.round(date.getTime() / 1000);
if (ts - last_scheduled_update > 60 || _force_scheduled_update) {

Sommige developers zijn blijkbaar nog niet bewust van keuzes die ze maken, want stel dat deze applicatie door een proxy moet om bij Internet te komen. Dan wordt die proxy server ook onnodig belast, terwijl veel mensen echt niet zitten te wachten op een refreshrate van de data in een webapplicatie elke 10 seconden. Zeker niet als er voldoende tekst is om te lezen om een minuut of langer mee te vullen.

Is CDDL genoeg of niet?

Op de NLOSUG-mailinglist is een discussie ontstaan over het voortbestaan van OpenSolaris nu Oracle eigenaar is geworden van Sun Microsystems. Het meest interessante punt is dat mensen denken dat een licentie automatisch hun investering kan beschermen, maar is dat wel zo? Geeft CDDL die garantie zoals GPL bijvoorbeeld?

3.1. Availability of Source Code.
Any Covered Software that You distribute or otherwise make available in Executable form must also be made available in Source Code form and that Source Code form must be distributed only under the terms of this License. You must include a copy of this License with every copy of the Source Code form of the Covered Software You distribute or otherwise make available. You must inform recipients of any such Covered Software in Executable form as to how they can obtain such Covered Software in Source Code form in a reasonable manner on or through a medium customarily used for software exchange.

Dit lijkt minder strikt dan de voorzieningen in GPL, maar juristen kunnen dit mogelijk beter beantwoorden. Het meest interessante wat kan gebeuren als Oracle besluit als 100% eigenaar van de code om de licentie te veranderen en OpenSolaris laat voor wat het is. Dit kan misschien weleens de belangrijkste gebeurtenis in de FOSS-wereld zijn van de afgelopen 10 jaar. Zoals ook besproken is bij DebConf 6 bijvoorbeeld.

Het laat misschien ook zien hoe open sommige bedrijven echt (kunnen) zijn en dat het altijd verstandig is om een kopie te hebben de broncode. Wat het ook laat zien hoe lastig het is om voor een groot bedrijf om te veranderen van bedrijfs- en verdienmodel waarbij je iedereen tevreden wilt houden. Zeker in een wereld die heel snel aan het veranderen is waarbij het model gaat van voornamelijk aanschafkosten naar een subscribermodel, zodat de kosten alleen daar zijn waar je ze ook verbruikt.

Theora ondersteuning in Firefox 3.1

Bij oa Tweakers is te lezen dat de webbrowser Firefox werkt aan ondersteuning voor het vrije videoformaat Theora. Bij de volgende release welke op de planning staat voor eind 2008 zal de webbrowser dus out-of-the-box dit formaat gaan ondersteunen. En hoewel dit niet interessant lijkt en door sommige zelfs als bijna onbegrijpelijk wordt gezien zijn er ook mensen die zien wat men probeert te bereiken. Zeker nadat bedrijven zoals Apple en Nokia hun eigen formaat bij HTML5 probeerde door te drukken om zo extra licenties te kunnen verkopen.

En een gedeelte van de beweringen zijn waar. Theora is van een mindere kwaliteit dan je misschien zou willen, maar het is voldoende nu voor menig YouTube filmpje. Daarbij is de kwaliteit vaak hoger dan men verwacht en de opnames van oa de DebConf-meetings uit het verleden zijn daar wel een bewijs van. Een ander feit blijft dat veel nieuwe codecs meer vragen van het systeem om de betere kwaliteit ook daadwerkelijk te kunnen tonen.

Maar Mozilla speelt hier een slinks spel, want veel mensen zijn gemaks- en kuddedieren. Als iets werkt stapt men niet snel meer over naar iets anders of er moet een hele goede reden zijn. Men haalt dus een drempel weg voor de eindgebruiker en veel webdevelopers weten dus dat ze bij een client met Firefox 3.1 of hoger altijd een bepaalt formaat kunnen aanbieden wat altijd direct zal werken. De enige vraag blijft over hoe de markt en de concurrentie hierop zal reageren.