19.09.2017 Views

the-web-application-hackers-handbook

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

818 Chapter 21 n A Web Application Hacker’s Methodology<br />

5.5.2 Identify any instances where session tokens are transmitted within <strong>the</strong><br />

URL. It may be that tokens are generally transmitted in a more secure<br />

manner, but that developers have used <strong>the</strong> URL in specific cases to<br />

work around a particular problem. If so, <strong>the</strong>se may be transmitted in<br />

<strong>the</strong> Referer header when users follow any off-site links. Check for any<br />

functionality that enables you to inject arbitrary off-site links into pages<br />

viewed by o<strong>the</strong>r users.<br />

5.5.3 If you find any way to ga<strong>the</strong>r valid session tokens issued to o<strong>the</strong>r users,<br />

look for a way to test each token to determine whe<strong>the</strong>r it belongs to an<br />

administrative user (for example, by attempting to access a privileged<br />

function using <strong>the</strong> token).<br />

5.6 Check Mapping of Tokens to Sessions<br />

5.6.1 Log in to <strong>the</strong> <strong>application</strong> twice using <strong>the</strong> same user account, ei<strong>the</strong>r from<br />

different browser processes or from different computers. Determine<br />

whe<strong>the</strong>r both sessions remain active concurrently. If <strong>the</strong>y do, <strong>the</strong> <strong>application</strong><br />

supports concurrent sessions, enabling an attacker who has<br />

compromised ano<strong>the</strong>r user’s credentials to use <strong>the</strong>se without risk of<br />

detection.<br />

5.6.2 Log in and log out several times using <strong>the</strong> same user account, ei<strong>the</strong>r from<br />

different browser processes or from different computers. Determine<br />

whe<strong>the</strong>r a new session token is issued each time, or whe<strong>the</strong>r <strong>the</strong> same<br />

token is issued every time <strong>the</strong> same account logs in. If <strong>the</strong> latter occurs,<br />

<strong>the</strong> <strong>application</strong> is not really employing proper session tokens, but is<br />

using unique persistent strings to reidentify each user. In this situation,<br />

<strong>the</strong>re is no way to protect against concurrent logins or properly enforce<br />

session timeout.<br />

5.6.3 If tokens appear to contain any structure and meaning, attempt to separate<br />

out components that may identify <strong>the</strong> user from those that appear to be<br />

inscrutable. Try to modify any user-related components of <strong>the</strong> token so<br />

that <strong>the</strong>y refer to o<strong>the</strong>r known users of <strong>the</strong> <strong>application</strong>. Verify whe<strong>the</strong>r<br />

<strong>the</strong> <strong>application</strong> accepts <strong>the</strong> resulting token and whe<strong>the</strong>r it enables you<br />

to masquerade as that user. See Chapter 7 for examples of this kind of<br />

subtle vulnerability.<br />

5.7 Test Session Termination<br />

5.7.1 When testing for session timeout and logout flaws, focus solely on <strong>the</strong><br />

server’s handling of sessions and tokens, ra<strong>the</strong>r than any events that occur<br />

on <strong>the</strong> client. In terms of session termination, nothing much depends on<br />

what happens to <strong>the</strong> token within <strong>the</strong> client browser.

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

Saved successfully!

Ooh no, something went wrong!