1 / 19

Chapter 7

Chapter 7. Attacking S ession Management Juliette Lessing. Session management Enables the application to uniquely identify a given user across a number of different requests . Prime target for malicious attacks against application . Encountered defects.

nan
Télécharger la présentation

Chapter 7

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Chapter 7 AttackingSession Management Juliette Lessing

  2. Session management • Enables the applicationtouniquelyidentify a given user across a number of different requests. • Prime target formalicious attacks againstapplication. • Encountered defects.

  3. Two types of weaknesses • Weaknesses in Session Token Generation • Weaknesses in the handling of session tokens throughouttheirlifecycle.

  4. Weaknesses in Session Token Generation • Meaningful tokens (1) • Createdusing a transformation of the user’s user name or other info associatedwiththem • But actually:

  5. Meaningful tokens (2) • Exhibitsomestructureallowinganattackertounderstandtheirfunctionand means of generation. • Components: • User name • E-mail address • Client’s IP address

  6. Meaningful tokens (3) • Hack steps: • Obtain single token from the application, modifyittodeterminevalidity. Change token’svalueone byte at a time and check whetherapplication is stillaccepted. Are someportionsnotrequiredtobe correct, exludethem. • Log in as several different users at different timesand record the tokens receivedfrom the server. • Analyze the tokens foranycorrelationsthatappeartoberelatedto the username andother user-controllable data. • Analyzethe tokens foranydetectableencoding or obfuscation. • Ifanymeaningcanbe reverse engineeredfrom the sample of session tokens, guess the tokens, finda page of the applicationthat is session-dependent, andmake large numbers of requeststothis page using these guessedtokens. Monitor the resultsforany cases where the page is loadedcorrectly, indicating a validsession token.

  7. Weaknesses in Session Token Generation • Predictable tokens (1) • Containsequences or patterns • Arisefrom 3 different sources: • Concealedsequences • Time dependency • Weak random numbergeneration

  8. Predictable tokens (2) • Concealedsequences •    

  9. Predictable tokens (2) • 2. Time dependency Attack: • Start pollingthe server toobtain new session tokens in quicksuccession • Monitor the increments in the first number. Increases more thanone? Token has been issuedbyanother user • We knowupperandlowerbounds of second numberwhich was issuedtothem • brute-force attacks in order tosuccessfully access a protected page • Running thisscripted attack continuouslywillenableustocapture the session token of everyotherapplication user. Whenanadministrative user logs in, we willfullycompromise the entireapplication.

  10. Predictable tokens (3) 3. Weak random numbergeneration Thisalgorithmtakes the last numbergenerated, multipliesitbyone constant, andaddsanother constant, toobtain the next number. The number is truncatedto 48 bits, and the algorithmshifts the resultto return the specificnumber of bits requestedby the caller.

  11. Weaknesses in Session Token Handling • Disclosure of tokens on the network (1) • Weaknessesoccurwhen: • Someapplications elect touse HTTPS toprotect the user’scredentialsduring login but thenrevertto HTTP for the remainder of the user’ssession • Someapplicationsuse HTTP forpreauthenticatedareas of the site, such as the site’s front page, but switch to HTTPS from the login page onwards.

  12. Disclosure of tokens on the network(2) • Hack steps: • Walk throughapplication in normal way andidentify login functionsandtransitionsbetween HTTP and HTTPS communications • Are HTTP cookies usedas transmission mechanism? Verifywhether secure flag is set • Determinewhethersession tokens are ever transmitted over anunencryptedconnection. Yes? Regardthem as vulnerabletointerception • Verifywhether a new token is issuedfollowing login, or whether a token transmittedduring the HTTP stage is stillbeingusedto track the user’sauthenticedsession • Verifywhether server is listening on port 80. Ifso, visitany HTTP URL directlyfromwithanauthenticatedsessionandverifywhether the session token is transmitted • In cases where a token foranauthenticatedsession is transmittedto the server over HTTP, verifywhetherthat token continuestobevalid or is immediatelyterminatedby the server.

  13. Weaknesses in Session Token Handling • Disclosure of tokens in logs • causesof session tokens appearing in system logs

  14. Weaknesses in Session Token Handling • Vulnerablesessiontermination (1) • Someapplications do notprovideeffectivelogoutfunctionality: • A log-out function is notimplemented • The logoutfunction does notactuallycause the server toinvalidate the session • Whena user clicks Logout, thisfact is notcommuni- catedto the server at all, andso the server performs no action whatsoever.

  15. Vulnerablesessiontermination (2) • Hack steps: • Investigatewhethersessionexpiration is implemented on the server side • Determinewhether a logoutfunctionexistsand is prominently made availableto users. Ifnot, users are more vulnerablebecausethey have no means of causing the applicationtoinvalidatetheirsession. • Where a logoutfunction is provided, test itseffectiveness. Afterlogging out, attempttoreuse the old token anddeterminewhetherit is stillvalid. Ifso, users remainvulnerabletosomesessionhijacking attacks even afterthey have “logged out.”

  16. Weaknesses in Session Token Handling • Client Exposure to Token Hijacking • Hack steps (1): • Identifyany cross-site scriptingvulnerabilitieswithin the applicationanddeterminewhether these canbeexploitedtocapture the session tokens of otherusers • If the application issues session tokens tounauthenticated, obtain a token andperforma login.

  17. Hack steps (2): • Check whether the application is willingto return to the login page eventhoughyou are alreadyauthenticated, sumbitanother login as a different user using the same token. Ifit does not issue a fresh token, it is vulnerabletosessionfixation • Identifythe format of session tokens usedby the application. Modifyyour token toaninventedvaluethat is validlyformed, andattemptto login. If the applicationallowsyoutocreateanauthenticatedsessionusinganinvented token, thenit is vulnerabletosessionfixation.

  18. SecuringSession Management • In order toperformsession management in a secure manner: • Generate strong tokens • Protect Tokens throughoutTheirLifecycle • shouldonly ever betransmitted over HTTPS • never betransmitted in the URL • Logoutfunctionalityshouldbeimplemented • Sessionexpirationshouldbeimplementedafter a suitableperiod of inactivity (e.g., 10 minutes). • Etc.

  19. SecuringSessionManagement • Per-page Tokens • New page is createdevery time • Preventssessionfixation attacks

More Related