19.09.2017 Views

the-web-application-hackers-handbook

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

756 Chapter 20 n A Web Application Hacker’s Toolkit<br />

through ei<strong>the</strong>r tunnel, gain access to its cleartext form, and <strong>the</strong>n reencrypt it<br />

for transmission through <strong>the</strong> o<strong>the</strong>r tunnel.<br />

Attacker<br />

Internet<br />

Target<br />

CONNECT wahh-app:433<br />

200 Connection established<br />

Intercepting proxy<br />

SSL tunnel 1 SSL tunnel 2<br />

1101001000100<br />

11010100000...<br />

GET / HTTP/1.1<br />

User-Agent: Mozilla/<br />

4.0 (compatible; MSIE<br />

7.0; Windows NT 5.1)<br />

Host: wahh-app.com<br />

...<br />

1001001101000<br />

10001001001...<br />

1100100110010<br />

01010101110...<br />

HTTP/1.1 200 OK<br />

Content-Type: text/<br />

html<br />

Content-Length:<br />

24246<br />

...<br />

0010010100001<br />

01111010100...<br />

Figure 20-3: An intercepting proxy lets you view and modify HTTPS communications<br />

Of course, if any suitably positioned attacker could perform this trick without<br />

detection, SSL would be fairly pointless, because it would not protect <strong>the</strong><br />

privacy and integrity of communications between <strong>the</strong> browser and server. For<br />

this reason, a key part of <strong>the</strong> SSL handshake involves using cryptographic<br />

certificates to au<strong>the</strong>nticate <strong>the</strong> identity of ei<strong>the</strong>r party. To perform <strong>the</strong> server’s<br />

end of <strong>the</strong> SSL handshake with <strong>the</strong> browser, <strong>the</strong> intercepting proxy must use<br />

its own SSL certificate, because it does not have access to <strong>the</strong> private key used<br />

by <strong>the</strong> destination server.<br />

In this situation, to protect against attacks, browsers warn <strong>the</strong> user, allowing<br />

her to view <strong>the</strong> spurious certificate and decide whe<strong>the</strong>r to trust it. Figure 20-4<br />

shows <strong>the</strong> warning presented by IE. When an intercepting proxy is being used,<br />

both <strong>the</strong> browser and proxy are fully under <strong>the</strong> attacker’s control, so he can<br />

accept <strong>the</strong> spurious certificate and allow <strong>the</strong> proxy to create two SSL tunnels.<br />

When you are using your browser to test an <strong>application</strong> that uses a single<br />

domain, handling <strong>the</strong> browser security warning and accepting <strong>the</strong> proxy’s

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!