[WEB SECURITY] Need a vulnerable XML Web Service
andreg at gmail.com
Wed Jun 9 01:13:20 EDT 2010
On Tue, Jun 8, 2010 at 7:28 PM, Arian J. Evans
<arian.evans at anachronic.com> wrote:
> 1. How many web services have you seen?
> 2. What technologies do they use? (protocol, standards, format)
Serialized XML over HTTP/TLS, almost never using any standards except
maybe a WSDL (never WADL or WSDL 2.0); almost never using SOAP
(although used to a lot more circa 2000-2005). Supposedly something
called WS-Security exists. Gunnar talks about that stuff, but you
never really see it unless you follow up working for some place that
he worked for (and then you're work is really cut out for you).
> 3. What type of vulnerabilities do you actually discover on them?
Looks like that first dude claims AuthN/Z are the most common but the
second dude seems to think that XSD mutations and higher-order SQLi
and DoS are real bad.
I'm going to say that the AuthN/Z issues are largely fixed via proper
threat-modeling and balanced-but-not-idiotic trade-offs during the
design phase (or elaboration sprint, or "the stuff you do way before
you produce an iterative demo", for all of you ScrumMasters out
there). You implement TLS. You provide session management that rocks.
You separate and encrypt databases properly. You don't give overly
permissive privileges to the app or any user/service function, etc.
You are careful with things like storage and rotation of credentials
and separation of duties. You encrypt the sensitive traffic on your
message bus. You provide logging, accounting, alerting, monitoring,
etc -- for accountability and incident handling purposes in addition
to monitoring performance and functionality. Etc.
However, when it comes down to implementing or constructing a Web
Services system you have to think about a few things:
1) Proper error handling
2) Concurrency or other issues that lead to Denial of service
3) Log erasure or forging
4) XML validation
5) SQL injection
6) Command or other injection
Some of this can be done through threat-modeling, but app developers
need more than just a few guidelines. Big companies such as BofA put
SOAPSonar in the hands of developers to test the Web Services, but
this sort of tool needs to be used like Burp Suite or Fiddler2 -- you
have to use your brain. You can't just slap fuzzdb or whatever into
the tool, although it may not hurt to use portions of fuzzdb when
performing your testing. It's more about identifying dynamic, large
parameter operations that yield large XML files and torturing them in
the right places, as well as identifying the smaller parts of the app
that perform simple-but-stupid operations.
> 4. What issues can be found in a default scan vs. which issues require expert configuration of the scanner?
I don't know what you mean by "scanner". Are you talking about one of
Those things suck! If I were you, I'd stop using one of those and grab
this other tool called "Burp Suite Professional" or perhaps a free
passive tool such as Fiddler2 with Casaba Watcher or Google Ratproxy
(with the MSF WMAP patches).
> That would be interesting data, and help folks prioritize what to put into test apps like WebGoat, and provides data to correct any biases that the same of WS I've seen include.
Also try http://crosschecknet.com/demo/accounts.php
I saw it in one of those slides from my above links. I've used that
tool, SOAPSonar, before -- some good screenshots of it in that prezo.
I suggest checking it out if all you do all day is test Web Services.
Personally, I'd go with my earlier suggestions such as mapping URLs to
source code (I hear REST parameters usually map directly to individual
source files) or using Fortify PTA with a pre-designed test harness.
What would be really cool is if we could automate Web Services
vulnerability assessments so that XML Firewalls could just block the
attacks found. (Just kidding! That would NEVER work. HAHAHAHAHAHAHA)
Join us on IRC: irc.freenode.net #webappsec
Have a question? Search The Web Security Mailing List Archives:
Subscribe via RSS:
http://www.webappsec.org/rss/websecurity.rss [RSS Feed]
To unsubscribe email websecurity-unsubscribe at webappsec.org and reply to
the confirmation email
Join WASC on LinkedIn
More information about the websecurity