May 28, 2010

Last days in Amsterdam

These are my last days as a resident of Amsterdam. This morning I submitted my petition to deregister to Gemente Amsterdam. Starting in June, I will reside near the beautiful Swiss Alps.

Tot ziens Amsterdam und grüezi Zurich!

May 26, 2010

Bugs, security, input validation...

Gabe has 2 very interesting posts on the topic of validating input:
  • Input Validation & Injection Vulnerabilities

  • OWASP and Input Validation


  • A definitely recommended read.

    May 16, 2010

    Domain names in Cyrilic

    Veni Markovski wrote:
    http://президент.рф is up and running! congratulations, Russia!!!


    Well done, ICANN! We now have domain names in Cyrilic!

    I suspect this will have a lot of security implications, but from an internationalization perspective, it's awesome! :)

    May 13, 2010

    Business Models

    Roussi sent me the following example of the different business models... have to appreciate the analogies here. :)

    Mar 13, 2010

    To validate or not to validate... that is the question!

    Secure development guidance preaches that all input should be validated for length, format, type, and value as appropriate. Typically, guidance stretches along the lines of validate all input that your code takes and validate accordingly. A few years ago there was a similar belief that input validation can stop cross-site scripting. Although this is partially true, full remediation of cross-site scripting is achieved by properly encoding the input data according to the context in which it is later outputted.

    So here comes my question, in order to validate input properly, isn't it better to have the validation to be performed by the code that will act on it as opposed to having the validation at the trust boundary of the overall app? Example: Component1 uses Component2 for backend logic. If Component1 only passes the data straight through to Component2, my belief is that Component1 should leave the input validation to Component2. Thoughts?

    Mar 4, 2010

    SDL courses in the public

    A while ago I was pointing out some interesting stats about the secure development lifecycle (SDL). Last week, Microsoft made its four core SDL training classes available to the public. The titles are:
    - Basics of Secure Design Development Test
    - Introduction to the Microsoft Security Development Lifecycle (SDL)
    - Introduction to Threat Modeling
    - Privacy in Software Development


    I would encourage everyone with a bit of spare time to take a look at these courses.

    Mar 2, 2010

    The daily /.

    A few interesting stories from my daily /.-ing:

    1. CAPTCHA troubles
    "Ticketmaster used various means to try to thwart Wiseguy’s operation, at one point switching to a service called reCAPTCHA, which is also used by Facebook. It’s a third-party CAPTCHA that feeds a CAPTCHA challenge to a site’s visitors. When a customer tries to purchase tickets, Ticketmaster’s network sends a unique code to reCAPTCHA, which then transmits a CAPTCHA challenge to the customer.

    But the perpetrators were able to thwart this as well. They wrote a script that impersonated users trying to access Facebook, and downloaded hundreds of thousands of possible CAPTCHA challenges from reCAPTCHA. They identified the file ID of each CAPTCHA challenge and created a database of CAPTCHA “answers” to correspond to each ID. The bot would then identify the file ID of a challenge at Ticketmaster and feed back the corresponding answer. The bot also mimicked human behavior by occasionally making mistakes in typing the answer, the authorities said."

    After having a chat with Aldwin on the topic, it seems like this might be a serious flaw in CAPTCHA (i.e. mapping a challenge to a response via identifying the filename of the CAPTCHA image). After all, CAPTCHA should allow developers to feed arbitrary text that will then get rendered on the fly.

    The original article is here.


    2. Nearly 60% of apps fail first security tests. Interesting number from Veracode; however, I wonder in what phase of the SDLC were those apps when they were tested. Although I agree with their argument that more work is required in educating the developers, I must also add that more tooling is necessary (e.g. code annotations, code scanning when committing code to the repository, etc.) to enable developers focus on the bigger security problems.

    More on the topic here.