140 likes | 235 Views
XML and Web Services. Chapter 10. Topics. Why a standards-compliant XML parser Why a standard (off the shelf) XML parser Validation. External references Document queries Input validation for Web services WSDL potential problems/a bad example with blacklisting
E N D
XML and Web Services Chapter 10
Topics • Why a standards-compliant XML parser • Why a standard (off the shelf) XML parser • Validation. • External references • Document queries • Input validation for Web services • WSDL potential problems/a bad example with blacklisting • New opportunities for old errors • JavaScript hijacking..
Introduction • XML • web services • Service oriented architecture The promise: • Software reuse • Less software security headaches
Why a standards-compliant XML parser • XML is very hard to parse • Recursive • XML entities (&xxxx;) • Better to use a standard, off the shelf XML parser; there are many...
Validation • Validating XML documents can be done against an XML schema or Document Type Definition (DTD) • Slight preference for XML Schema because “Simple Object Access Protocol” (Soap) uses XML schema and SOAP used for man Web Services standards. • Can be tricked, so be careful (page 354 has a good example of “XML injection”)
External References • Document queries may be malicious, so be careful about following them! Example Document Type Declaration: <!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Strict//EN” “http://www.w3.org/TR/xhtml1/DTD/strict.dtd”> • One example redefined the XML parser (ref. P 359) • Another example exported the boot sector. Recommendation: use XML Schema (easier, more powerful)
Document Queries Looking around in XML documents is difficult. Solution: XPATH Problem: XPATH queries can be subject to XPATH injection if not validated correctly. (See example and cure on pp 363-365
Web Services • Web services are the main reason firewalls are not too useful • Proponents often equate security features with secure features. • Many chances for problems.
Input validation for Web Services WS frameworks make it easy to “push a button” and get a web service. Case in point: Class xxx.java is copied into webapp directory as <webapp>/axis/xxx.jws Now xxx is available via SOAP, with all its vulnerabilities!!!
WSDL potential problems/a bad example with blacklisting • WSDL stands for Web Services Description Language: does for Web Services what HTML does for web pages: makes them “discoverable. • Example: Direct Web Remoting (DWR) (see http://directwebremoting.org/dwr/index.html) has a facility that allows listing “excluded” methods: • <exclude ...> • <include ...> • DWR is another easy way to include java code in a web services page.
New opportunities for old errors • Automatic Stack traces ??? • Session management traps • Ambiguous security requirements: • Versatility vs security (XSS for example)
JavaScript Hijacking • AJAX is a well used platform for developing Web applications; it is very easy to use. • Biggest problem is that browser requests are for small datapieces, leaving the door open for attackers to steal data (technology exists to mix data sources, similar to mash-ups). Confidential data can be retrieved by a malicious website. Very possible with XSS. Advice: • Decline malicious requests • Prevent direct execution of JavaScript responses.
Declining Malicious Requests A Javascript hijacking attempt looks like an XSS. Suggest: Include a random cookie (can be a session or a dialog cookie) Check the HTTP referer header. Do not respond to GET requests. (Always used by <script> tag) (efficiency hit)
Preventing direct response execution Program in such a way that responses include code that has to be removed in order to make it executable: for example, prefix it with: While(1); or convert the code into comments (enclose in /* */)