August 2008 - posts - Ruud de Jonge

Ruud de Jonge

over Microsoft Platform en Security ontwikkelingen

August 2008 - posts

Messenger op je mobiel .... Campagne met Silverlight 2

MobileMessenger-4Check de User Experience (UX) blog van Martin Tirion. Mega mooi voorbeeld van een Silverlight 2 applicatie als promotie van Messenger op je mobiel. Ik ben verkocht :-)

De campagne is hier te  bekijken.

N.B. Overigens loont het zeker om de blog van Martin in de gaten te houden. Coolness^2

Posted: Aug 28 2008, 10:25 PM door Ruud de Jonge | met no comments
Opgeslagen onder: ,
Wow : Panorama Mesdag op Photosynth

Panorama Mesdag is a cylindrical painting, more than 14 meters high and 120 meters in circumference. The vista of the sea, the dunes and Scheveningen village was painted by one of the most famous painters of the Hague School, Hendrik Willem Mesdag. It is the oldest 19th century panorama in the world in its original site, and a unique cultural heritage.

En te vinden op :

Oh nee !!! Mijn website doet het niet in ie-eee !!!!! (Internet Explorer 8)

Download now Gisteren is Beta 2 van Internet Explorer 8 beschikbaar gemaakt. Naast de verschillende nieuwe features, bestaat er een gedegen kans dat je website er "anders" uit ziet. Dus ...

Dit fenomeen wordt veroorzaakt door het feit dat Internet Explorer 8 zich beter houdt aan de webstandaarden en daar kan zich nu een probleem voordoen als je site is geoptimaliseerd voor eerdere versies van Internet Explorer. (De discussie over standaarden wil ik overigens hier niet aansnijden :-), daar zijn betere gelegenheden voor)


Om er zeker van de zijn dat JOUW site het wel doet, neem de volgende stappen :

Infoworld review over Visual Studio 2008 SP1

Visual Studio 2008 LogoVolledige tekst :


De conclusie van dit 2-pagina lang artikel is duidelijk :

Time-consuming, but worth it
I haven’t found any downside to installing VS08 SP1, other than the time; it took me several hours to download and install it over a relatively good broadband connection: if I had to do it again, I’d kick it off just before I went home for the day. Note that the updated MSDN documentation requires a separate download and installation. Once installed, the SP1 changes are, in my experience, all good. Unless you have add-ons or SDKs that still require Visual Studio 2005 (the .Net Micro Framework comes to mind), I don’t see any reason for a Microsoft shop not to completely switch over to Visual Studio 2008 SP1.

SP1 en .NET Framework 3.5 SP1 is te downloaden via :

Posted: Aug 26 2008, 09:01 PM door Ruud de Jonge | met no comments
Opgeslagen onder: , ,
Code Camp op 6 september 2008 in Barneveld


Software Development Network Newsletter

Beste Ruud de Jonge,

Tijd om je even los te scheuren van het Olympisch festijn en je agenda te pakken. Op 6 september 2008 organiseren de SDN, Stichting dotNed en VBcentral samen het tweede Nederlandse Code Camp.
De voorlopige sessie agenda staat nu online, zie de Tracks en Sessies pagina voor meer informatie!
Wat is een Code Camp? Er is een heus Code Camp manifest, maar in het kort: een dag van code, code sharing, freaking en gezellig samenzijn. Een evenement door ontwikkelaars, voor ontwikkelaars. De regie ligt voor een belangrijk deel bij de deelnemers! Het aantal plaatsen voor deelnemers is wel beperkt tot maximaal 120. Wacht dus niet te lang met beslissen want voor je het weet is er geen plaats meer.
Een Code Camp is volledig gratis voor alle deelnemers. Dit is mogelijk vanwege de geweldige bijdrage die wordt geleverd door onze sponsoren:

Gold Sponsor:
Silver Sponsor:

Hopelijk tot 6 september!

Met vriendelijke groet,
Mark Blomsma
Software Development Network

Het Software Development Network
Het Software Development Network, ofwel de SDN, is er door en voor ontwikkelaars, architecten en information workers. We zijn altijd op zoek naar auteurs die artikelen en/of tips & tricks voor willen schrijven. Heb je interesse? Stuur dan een mail naar de SDN redactie .

Heb je vragen, opmerking, ideeen of wil je meer weten over het Software Developer Network? Neem dan contact op met:
Joop Pecht
Postbus 506
7100 AM Winterswijk
Tel. (0543) 51 80 58
Fax(0543) 51 53 99

Posted: Aug 21 2008, 01:52 PM door Ruud de Jonge | met no comments
Opgeslagen onder:
Voeten op tafel in het hol van de "Leeuw" ? : 3 nieuwe sessies in het najaar van 2008

Na de eerste "Voeten op tafel" sessies van begin dit jaar en de aandacht die dit opleverde :-), kan het geen kwaad om de volgende sessies te plannen. Op de volgende data is een ieder van harte welkom :

  • Donderdag 18 september 2008 van 16:00 tot ?
  • Donderdag 16 oktober 2008 van 16:00 tot ?
  • Donderdag 20 november 2008 van 16:00 tot ?

Onderwepen (die je natuurlijk zelf bepaalt ...) :

  • Historie Microsoft
  • Open Standaarden
  • Open Source
  • Open XML & ODF
  • Vista
  • OEM's (zij leveren je Vista bij je nieuwe PC)
  • Office 2007
  • Europese Commissie
  • ...
  • Om ervoor te zorgen dat de eventuele borrelnootjes niet na 10 minuten op zijn, laat even weten of je wilt komen op met vermelding van de datum van je voorkeur.

    Let op !!


    Posted: Aug 21 2008, 11:14 AM door Ruud de Jonge | met 3 comment(s)
    Opgeslagen onder:
    Welcome to Photosynth

    Posted Wednesday, August 20, 2008 7:20 PM by synthy

    We’re pleased to announce the first full release of Photosynth, available now at  Photosynth takes a collection of regular photographs and reconstructs the scene or object in a 3-D environment.  For those of you who have seen the videos or tried our tech preview, you could experience synths that we made in the lab and get a feel for what Photosynth is and how it works.  But now, for the first time ever you can create synths from your own pictures and share them with your friends.  Explore great synths from others or create a few of your own.

    Don’t know where to start?  Check out these great synths available today:

    While there are plenty of interesting synths to check out already, the best ones will come from you.  If you need help creating a killer synth, check out our photography guide for some tips.  Or just watch our short how to synth video which gives you a quick overview of the best way to take pictures that will make a good synth.

    photosynth home page

    Because Photosynth is so new, you will probably run into an occasional bug or hiccup.  Whether you have a brilliant idea or find a bug, please let us know.  We’ll do our best to address them.

    And be sure to keep watching this space, where we’ll share what we’ve learned about making great synths, talk with some members of the Photosynth team, provide synthing suggestions for advanced users and point you to some of the cooler synths that people are building.

    Former New York Jets Quarterback Joe Namath once said “When you have fun, you can do amazing things.”   We sure hope you have as much fun using Photosynth as we’ve had building it

    Posted: Aug 21 2008, 10:36 AM door Ruud de Jonge | met no comments
    Opgeslagen onder: ,
    IE 8 XSS Filter Architecture / Implementation

    Recently we announced the Internet Explorer 8 XSS Filter and talked a bit about its design philosophy. This post will describe the filter’s architecture and implementation in more detail.

    Design Goals

    The Internet Explorer 8 XSS Filter is intended to mitigate reflected / “Type-1” XSS vulnerabilities in a way that does not “break the web.” Our baseline approach needs to satisfy the following three conditions:

    • The XSS Filter must be compatible.
      • There should be minimal, ideally zero, disruption to benign content/data. We might be able to achieve effective filtering if we were to drop all non-alphanumeric characters from input, however this would be an unrealistic and overbearing solution. Any solution that involves directly modifying request URLs is likely to persist corrupted data on the server-side. Similarly, approaches that would ask the user questions they can’t answer or block entire pages are not acceptable.
    • The XSS Filter must be secure.
      • In general it must not be possible to subvert the filter by modifying attacks that are otherwise intentionally blocked. Although the XSS Filter cannot mitigate all possible XSS attacks, it can win some critical battles decisively. We can push as far as possible to maximize the XSS Filter’s effectiveness as long as we are also careful not to compromise compatibility or performance.
    • The XSS Filter must be performant.
      • Users prefer a fast browser to a slow one, even if the slower one is “more secure.” So some approaches are simply not acceptable for performance reasons. For example, creating an extra instance of the browser rendering engine for each navigation would be too impactful to consider.

    In implementing the filter, we made decisions to best meet the above goals.

    Practical Considerations

    The XSS Filter must be in a position to observe and intercept requests and responses from the browser to the web server. In Internet Explorer, this is possible via a MIME Filter. The prototype implementation of the XSS Filter was in fact implemented as a MIME Filter, but for performance it was moved into MSHTML (the browser rendering engine) when we built Internet Explorer 8.

    Architecture / Implementation

    Figure A: XSS Filter Hosted in Internet Explorer 8

    Figure B: XSS Filter Logic Flow

    Figures A and B depict a high level view of the XSS Filter. Let’s dig into the details.

    For performance, the XSS Filter only takes effect for navigations within the browser which can result in the execution of script. There’s no need for the XSS Filter to operate on resources such as images (as long as they are truly images when rendered by Internet Explorer).

    The filter also checks the source and destination URLs of navigations within the browser. If the navigation is cross-site, or the source cannot be determined (ex: the user clicked on a Favorite) then the navigation is filtered.

    The XSS Filter can be enabled/disabled per-zone. For the Beta 2 release the XSS Filter will be enabled for the Internet and Restricted Sites zones, but not the Local Intranet zone. Administrators can choose to enable or disable the XSS Filter for any zone via group policy.

    The core XSS Filter engine operates in two stages:

    1. HTTP GET / POST data is scanned to match a set of heuristics that identify XSS attack vectors. Matches are used to build signatures to identify markup/script as replayed in the HTTP response.

    2. Generated signatures are used to scan the HTTP response. Markup/script which has been identified by a signature is neutered to block execution.

    Validating that an XSS attack has actually been replayed into the response maximizes XSS detection reliability – “reflected XSS” requires reflection. Having the capability to identify and neuter the replayed markup/script allows the filter to avoid overbearing mitigations such as querying the user, modifying outgoing requests, or blocking entire pages.

    Our approach is performant in that the only notable “heavy lifting” is the scan of the HTTP response body, which will only occur in cases where signatures are generated. Signature generation is highly indicative of an actual XSS attack and it is rare during everyday browsing.

    Fun with Regular Expressions – Part 1: Heuristics

    If a navigation has met the criteria for filtering, the filter takes the URL as well as any POST data associated with the request, decodes it as necessary, and uses regular expressions to identify XSS attack vectors. These case-insensitive patterns are the filtering heuristics. Here is an example:

    {<sc{r}ipt.*src[whitespace or forward-slash]*=}

    This heuristic will identify SCRIPT tags with SRC attributes. While SCRIPT tags may be common in HTML, their presence in a URL or POST data is one indication of an XSS attack.

    In the example heuristic above, note that the character within the inner braces is what we will refer to here as the neuter character. Each heuristic can have one or more neuter characters. Each neuter character, in this case ‘r’, indicates a character that will eventually be modified by the filter in the HTTP response body in order to block the XSS attack. The ‘#’ character is used as the neuter replacement character – it is effective in breaking HTML elements as well as script blocks into which it is injected.

    The selection of neuter characters in any heuristic is very important. The wrong neuter characters chosen for a heuristic can subvert the filter. As an example, picking a quote symbol as a neuter character would cause the filter to neuter quotes. A smart attacker could use this behavior to force a match and neuter a quote on a page, intending to enable an XSS attack that wouldn’t otherwise be possible.

    A match on a heuristic does not in and of itself trigger the filter to detect XSS. Rather, it indicates to the filter that the HTTP response body must be examined to validate that the script in the input URL or POST data was in fact replayed to the output page.

    The decoding process briefly mentioned above is flexible and can also account for artifacts of various web platforms. As necessary, the filter generates additional signatures (see below) based on alternate interpretations of the same input data. So for example, because malformed URLEncoded characters may be handled differently for different web platforms, the filter must be capable of building proper signatures regardless.

    Fun with Regular Expressions – Part 2: Signatures

    As heuristics are matched, the filter generates one signature for each match. A signature is a new regular expression that will be used to scan the HTTP response body for the replayed suspect input. The neuter replacement character is temporarily put into place in the input after a signature is matched. Matching then continues for a heuristic until no more matches can be found in the input. Signatures are generated for URLs without neuter replacement characters in place. Otherwise the signatures would themselves contain neuter replacement characters and they would not correctly match attacks present in the HTTP response.

    With each heuristic, a list of safe characters is provided. For the heuristic that detects script tags, the safe characters are the greater-than and less-than characters and also alpha-numerics. The safe characters effectively form the essence of the XSS attack the filter is attempting to identify.

    Why signatures?

    If the filter were to simply search for a match verbatim it would not necessarily find one. The web server may incidentally remove or translate particular characters from the request as it is replayed. It is in fact common and attackers can use this behavior to their advantage.

    Safe characters are restricted to the “low-ASCII” range (0x00 – 0x7F) so that we can essentially remain character-set agnostic. Character sets that are capable of alternate “low-ASCII” encodings (eg: UTF-7) are not currently special-cased, however some new restrictions are being placed on the general usage of these character sets moving forward. (These changes are outside the scope of this blog post but stay tuned to my blog for more details).

    Here is an example match for the heuristic that detects script tags:

    <SCRIPT src=””

    The signature generated for this match would be:


    Each ¤ in the signature indicates a non-safe character from the original match. A sequence of zero to N unspecified characters will match any ¤. (Currently N is 10)

    If no signatures have been generated for a particular page then the filter permits the page to load without modification – no XSS was detected.

    However, if signatures do exist, the filter scans the HTTP response body for each signature. Once identified, the filter records exactly which character(s) must be neutered, as indicated in the signature by the characters within the braces. Once the signature list is fully processed the neuter replacement characters are put into place and the HTTP response body is passed on to render in the browser.

    The page will render normally except the information bar will notify the user that the page was modified and the XSS attack will be disabled.

    XSS Filter Limitations

    Like all security mitigation and protection technologies, the XSS Filter’s approach does have limitations, being that it is a pragmatic balance between application compatibility, security, and performance. Some examples:

    • Injection into some contexts is not blocked. Ex: Scenarios where content can be injected directly into javascript without breaking out of a string.
    • Injections facilitated by some HTTP headers are not currently blocked. Ex: “Referer” based injection.

    • If a page contains multiple nearby injection points, attacks can be constructed that thwart the XSS Filter.

    These are all issues that undoubtedly occur on real web sites. The XSS Filter design philosophy dictates that we make a distinction between issues that generally enable the XSS Filter to be bypassed vs. issues that apply only in certain situations. The issues above, while very notable, clearly fall into the latter category. As time goes on we will continue to enhance the XSS Filter to maximize its effectiveness, however we will not compromise web site compatibility in the process.


    It is challenging to mitigate XSS in a way that balances the needs of compatibility, security, and performance. The XSS Filter’s two-stage approach helps us achieve these goals by very specifically targeting reflected (“Type-1”) XSS attacks. This architecture allows us to mitigate the XSS most commonly found across the web today, by default, for users of Internet Explorer 8.

    - David Ross, SVRD Blogger

    *Postings are provided "AS IS" with no warranties, and confers no rights.*

    August 19, 2008, 4:15pm: Updated with correct date

    Published Tuesday, August 19, 2008 4:16 PM by swiblog

    Filed under: IE, Internet Explorer, XSS Filter, XSS

    Posted: Aug 21 2008, 10:33 AM door Ruud de Jonge | met no comments
    Opgeslagen onder: