Software and web application security

February 19, 2007

Web Services denial of service attacks – XmlTextReader

Filed under: general — chrisweber @ 4:59 pm

Most Web Services I look at are built using the .NET Framework and ASP.NET. Today we’re seeing more with ASP.NET’s AJAX extensions but that’s a different story. Many developers choose to implement SOAP and XML as part of their WS solution, and in doing so can inadvertently open the application server up to DoS issues.

First there’s XML. When developers choose to implement XmlTextReader or XmlReader from the .NET Framework, they need to understand the behaviors of these classes. MSDN documents this quite well. I will usually do a quick code review to find implementations of these objects, because the issues can be identified a little faster through code than through testing.

XmlTextReader defaults to allowing external DTD’s to be specified. This leads to a whole enchilda of issues, and gives attackers a nice bit of control over the host server. Be sure to set the ProhibitDTD property equal to true. Furthermore, there’s no strict schema validation unless the developer implements one.SOAP is fine, but developers need to implement a custom SOAP extension to enforce strict schema validation. Otherwise it gets pretty easy for an attacker to abuse the WS by embedding things like:

  • large payloads
  • large number of elements
  • nested elements
  • malformed data

To name a few… Without strict validation, I’ve seen web services easily abused. For example, by sending a few large requests, it becomes trivial to consume memory on the host server which eventually leads to resource starvation. To learn more about implementing a custom SOAP Extension to tackle this problem, read the MSDN article:

February 10, 2007

Thinkpad as Wii?

Filed under: general — chrisweber @ 11:19 pm

Sweet, accelerometer used for much more than just the Active Protection System.

February 6, 2007

Checking ntoskrnl for rootkit

Filed under: general — chrisweber @ 12:27 pm

This is not new, but I needed it the other day and wanted to post it here for memory. In Microsoft’s kernel debugger tool ‘kd‘ the following command checks for binary corruption in every loaded module.  Note also that you can do this with Sysinternal’s ‘LiveKd‘ for easier on the fly debugging.

kd> !for_each_module !chkimg @#ModuleName

Make sure you have trusted modules to compare against first. And point to them before running the above command with:

kd> .exepath c:\Windows\system32

Create a free website or blog at