Rating: 5.0
## Challenge
## Initial reckoning
The web page shows a POST form that has a single text field called filename:
HTTP headers reveal that the server is a Microsoft-IIS/10.0 with ASP.NET 4.0.30319:
```http
HTTP/1.1 200 OK
Cache-Control: private
Content-Type: text/html; charset=utf-8
Server: Microsoft-IIS/10.0
X-AspNet-Version: 4.0.30319
X-Powered-By: ASP.NET
[...]
```
Using "Default.aspx" as the file name in the form retrieves the page source ?
... but wait, the source is available at http://52.197.162.211/Default.txt anyways.
Also, using "Default.txt" as the file name in the form retrieves that file. And
obviously we cannot access the flag at neither "C:\\FLAG.txt" nor "..\\..\\FLAG.txt" ?.
## Source code
```csharp
bool isBad = false;
try {
if ( Request.Form["filename"] != null ) {
isBad = Request.Form["filename"].Contains("..") == true;
}
} catch (Exception ex) {
}
try {
if (!isBad) {
Response.Write(System.IO.File.ReadAllText(@"C:\inetpub\wwwroot\" + Request.Form["filename"]));
}
} catch (Exception ex) {
}
```
## Interesting observations
My first though was something like "wtf? two separate try-catch-blocks?" Can we use
that for anything evil? Certainly `isBad` will remain `false` if the first exception
handler kicks in.
So how could we raise an exception in the first try-catch-block in order to permit
path traversal without raising an exception in the second try-catch-block?
- Can `String.Contains` raise an exception?
- Can `Request.Form[...]` return anything that does not have a `Contains()` member method
but still concatenates as useful string later on?
- Can `Request.Form[...]` raise an exception in some cases (particularly on first invocation) but not in others?
## Known bugs in ASP.NET 4.0 regarding request fields/forms?
So lets ask Google if there are any known bugs in ASP.NET ...
Interesting, [request validation has changed in ASP.NET 4.0](https://docs.microsoft.com/en-us/aspnet/whitepapers/aspnet4/breaking-changes#0.1__Toc256770147)
(right, that's the version of our attack target!). This seems to have resulted in many
complaints!
- [stackoverflow.com: A potentially dangerous Request.Form value was detected from the client](https://stackoverflow.com/q/81991/2425802)
- [How to prevent the Exception "A potentially dangerous Request.Form value was detected from the clientside" when Template column is used.](https://www.syncfusion.com/kb/9213/how-to-prevent-the-exception-a-potentially-dangerous-request-form-value-was-detected-from)
- [ASP.Net Error: A potentially dangerous Request.Form value was detected from the client](https://www.aspsnippets.com/Articles/ASPNet-Error-A-potentially-dangerous-RequestForm-value-was-detected-from-the-client.aspx)
- [how to try-catch potentially dangerous Request.Form value exception](https://bytes.com/topic/asp-net/answers/316222-how-try-catch-potentially-dangerous-request-form-value-exception)
That did not help so far ... but then I stumbled upon this: [There's actually someone\*
telling us that it might not be a good idea to ignore the exception that's thrown on **the first
access** to the `Request` collections.](https://www.nccgroup.trust/uk/about-us/newsroom-and-events/blogs/2017/september/rare-aspnet-request-validation-bypass-using-request-encoding/)
\*) NCC Group is certainly not just someone, but to be honest, I did not really care who's
exploit I could recycle back then ?.
## Basic idea
The basic idea of that vulnerability is that, for POST requests, request validation prevents
"dangerous content" (e.g. HTML tags or similar, such as `
