During one security assessment of an ASP.NET application, I find that it is possible to use "GET" requests to POST form data to the ASP.NET application. The application processes those form elements the same way as it is processing "POST" request. The web server logs those requests as "GET" requests instead of "POST" requests. This makes it convenient for the attackers to hide their attacks.
Here is a sample application:
protected void Page_Load(object sender, EventArgs e)
{
StringBuilder sb = new StringBuilder();
var forms = HttpContext.Current.Request.Form;
foreach (String s in forms.AllKeys)
{
sb.Append(string.Format("{0} => {1}", s, forms[s]));
sb.Append("
");
}
lblStatus.Text = sb.ToString();
}
The application is using HttpContext.Current.Request.Form to retrieve form element value. According to the documentation of MSDN (http://msdn.microsoft.com/en-us/library/system.web.httprequest.form),
The Form property is populated when the HTTP request Content-Type value is either "application/x-www-form-urlencoded" or "multipart/form-data".
As long as Content-Type value is either "application/x-www-form-urlencoded" or "multipart/form-data", the Form property is populated no matter whatever method the request is sent.
Here is one GET request with Content-Type and Content-Length headers:
The page looks like:
A check at IIS server shows the following entries:
14:46:04 127.0.0.1 GET /website3/default4.aspx 200
14:46:12 127.0.0.1 GET /website3/default4.aspx 200
14:46:12 127.0.0.1 GET /website3/default4.aspx 200
14:46:12 127.0.0.1 GET /website3/default4.aspx 200
14:46:14 127.0.0.1 GET /website3/default4.aspx 200
14:46:14 127.0.0.1 GET /website3/default4.aspx 200
14:46:14 127.0.0.1 GET /website3/default4.aspx 200
Next time, when you check your web server logs, do not ignore those simple "GET" requests because they might contain evil payloads to your applications.
{If the web server does not restrict HTTP verbs, you can use arbitrary verbs like PUT or XYZ to POST data to the application)
No comments:
Post a Comment