类系列产品,其品质优良,酿造工艺独.pptVIP

iDEFENSE Web Application Brute Forcing 101 – “Enemy of the State (Mechanism)” David Endler Michael Sutton Outline What are Session IDs? Security Problems with Session IDs An Emerging Threat - Brute Forcing Web Session ID’s Notable News Items Fun Exploitation Examples 6 Common Problems General Protection Measures Users Vendors Developers Resources Web Applications Logins Traditional Brute Force Session ID Overview HTTP is stateless protocol Rather than make a user authenticate upon each click in a web application, a sense of “state” is created In order to maintain state, a shared string, token, or secret between HTTP client and server is usually used by developers Essentially, authentication data (username/password) exchanged for “Session ID” Web State Attacks Session Replay A traditional replay attack in the cryptography sense is an attack in which a valid data transmission is maliciously or fraudulently repeated, either by the originator or by an adversary who intercepts the data and retransmits it. Session Hijacking Seizing control of a legitimate users web application session while that user is “logged in” to the application Session ID Session ID should IN THEORY be just as secure as username/password Session ID Overview While it is generally clear that username/password pairs are indeed authentication data and therefore sensitive, it is not generally understood that session IDs are also just as sensitive because of their frequent use for authentication. See RFC 2964 (Use of HTTP State Management). Session ID Overview Session IDs are commonly stored in cookies and/or URLs, and hidden fields of web pages (or some combination) Session ID generated by WEB SERVER (IIS, etc.) when the user first hits the site or by WEB APPLICATION (ATG dynamo, Apache Tomcat, BEA Websphere, .jsp, .asp, perl, etc.) when the user logs in Cookie Refresher Sometimes the cookies are set to expire (i.e., be deleted) upon closing the browser; these are typically called “session cookies