Do you ever get that sense that [insert culture here] seems to totally dominate everything to the total oblivion of everyone else out there? This sort of thing usually gets people a bit cranky but it turns out I’ve kind of being doing it a little bit myself with ASafaWeb.
You see, ASafaWeb works by looking at how a website responds to certain requests then and from those responses it draws some conclusions about how the thing is configured. For example, if ASafaWeb sees a response like the one below, it knows that custom errors have not been configured correctly:
It knows there was an error because the source code contains an <h1> tag which begins with the text “Server Error in”. ASafaWeb uses the HTML Agility Pack to easily strip this out of the response and then make some suggestions about how the app could be better configured.
So far, so good, but what happens when you see a response like this:
No, it’s not the CLR gone nuts, it’s just Dutch and the problem with Dutch is that it’s not English. Settle down, I say “problem” simply because you can’t apply the same spoken language logic as before and get away with it. Instead, we need to get a bit more creative…
Let’s take a look at the source code of the English error page:
<body bgcolor="white"><span><H1>Server Error in '/' Application.
<hr width=100% size=1 color=silver></H1>
And of the Dutch one:
<body bgcolor="white"><span><H1>Serverfout in toepassing /.
<hr width=100% size=1 color=silver></H1>
Fortunately, HTML markup in English is the same as HTML markup in Dutch so whilst the rendered to the page is totally different, the markup patterns are 100% identical. What this means is that ASafaWeb can change its logic from looking for that <h1> tag with the English error message to a condition more like this:
“If the <body> tag has a bgcolor attribute set to white and then contains a <span> tag which then contains an <h1> tag which then contains an <hr> tag with a width of 100%, a size of 1 and a color of silver, it’s an error page”
Now of course this could result in a false positive; it’s conceivable that someone has built their markup exactly the same. But really, who sets bgcolor attributes anymore?! Seriously though, the likelihood of a false positive is infinitesimally small, at least compared to the likelihood of not correctly identifying an error message presented in another language. And besides, if false positives do pop up, I’ll just add more markup matching found in other parts of the document. But it’s not going to happen.
Long story short, the ASafaWeb scans which identify a missing default redirect page, custom errors being off altogether or tracing being left on (and the trace.axd handler being accessible), are now all culturally sensitive. It doesn’t matter what language your server is running under, ASafaWeb will now correctly report on any of the security configuration vulnerabilities it scans for.
Update (28 March): Following the discussion in the comments below, I’ve decided to hedge my bets a bit. ASafaWeb now matches both the markup syntax described above and the old English-centric approach. This offers some insurance against future changes to the structure of the error and trace pages, although obviously it’s only English insurance. But hey, on the numbers, that’s pretty good coverage and obviously if there are markup changes later on, ASafaWeb will adapt to match that syntax too. Everybody should be happy :)