Web Security Testing : Changing Sessions to Evade Restrictions & Impersonating Another User

- Free product key for windows 10
- Free Product Key for Microsoft office 365
- Malwarebytes Premium 3.7.1 Serial Keys (LifeTime) 2019

1. Changing Sessions to Evade Restrictions

1.1. Problem

Some applications will prevent attackers from frequently accessing a form or page. One of the ways to bypass these protections is to frequently request new session identifiers so that the attacker appears as many new users rather than a single malicious user.

1.2. Solution

This recipe only applies if your application prevents an attacker from attempting to guess or sequentially attempt passwords, identifiers, or credentials.

Once you’ve identified an area where your application restricts multiple requests, go ahead and initiate as many requests as you can. Once you’re finished, you should now be locked out or otherwise prevented from trying again. At this point, open up Edit Cookies, filter by your current domain, select at least one cookie for your domain, and click the Delete button. Edit Cookies, by default, will ask you if you’d like to Delete or Cancel—but notice that there’s another option there, the Delete All option. Figure 1 shows the delete options. Click the Delete All option to erase all cookies, and hopefully all sessions, for your domain.

Figure 1. Deleting cookies

With the sessions gone, you should now be able to attempt the previously blocked actions again. If you repeat them enough and get blocked again, simply delete the cookies again to continue.

.3. Discussion

This ability to bypass detection and restrictions this way poses a difficult problem—how can one prevent repeated attempts? It turns out this is a very difficult problem. Tracking malicious attackers by IP address is a start—except that some users share IP addresses (think public wireless access points) and some attackers have access to many IP addresses (via a botnet). Server-side sessions aren’t safe, as cookies can be deleted at any time. Client-side sessions aren’t safe, as the client is completely controlled by the attacker anyway. Unfortunately, it appears that one can’t stop an attacker from trying, one can only slow them down. On the plus side, done well, one can slow an attacker down enough that cracking a password or credential should take a few years!

2. Impersonating Another User

2.1. Problem

If at this point you’re wondering what tests to apply when your application doesn’t use a session identifier, but instead relies on keeping the username in cookies, then this is the recipe for you. If your cookies contain any information about usernames and passwords, access permissions, or other authentication and authorization details, this can lead to trouble.

2.2. Solution

Via Edit Cookies, identify the authentication or authorization details being stored in cookies. We’ll go through the ramifications of each type of stored detail one by one:

Username only

If once the user logs in, only the username is stored in order to identify which user is which, then any user may impersonate any other user. To do so, you would open up Edit Cookies and modify the username cookie to contain another user’s username. The next time you browse to the application, the application will mis-identify you, allowing you to impersonate the other user.

Username and password

When the username and password are stored and checked together, an attacker can brute-force passwords at a rapid speed. To break into an account, the attacker sets up the cookies to contain the username and then rapidly iterates through new password cookies. An attacker could try many passwords without triggering any sort of account lockout. Once the password is broken, the attacker can login as and impersonate the user.

Access Controls or authorization details

If controls are defined in the cookies, try changing them via Edit Cookies. For example, if an account has a cookie with the name and contents ReadOnly and True, what happens if you change it to False, or rename the entire cookie? In this example, if your application allowed a ReadOnly user to make modifications, you’d have a clear vulnerability. While these don’t always allow one to impersonate another user, it does grant a user more access than was intended.

2.3. Description

Now you see why there’s such a focus on session identifiers. By using a session identifier, one essentially hides all the authentication and authorization details on the server. The only thing an attacker can guess about a session identifier is the session identifier itself—and if it’s random enough, that could take some time.

3. Fixing Sessions

3.1. Problem

Guessing passwords or session identifiers is hard work for an attacker. It’s much easier to trick a user into setting his own session identifier to something the attacker already knows. This is referred to as session fixation.

3.2. Solution

To set up this test, you’ll need to clear your browser’s cookies for your web application (via Edit Cookies or just by clearing all cookies via the Clear Private Data option in Firefox’s preferences). Once that’s done, navigate until your application sets a session identifier. You’ll have to check for the session identifier after each new page; this can be accomplished by first using Edit Cookies to filter for just your application’s domain and then refreshing the Edit Cookies filter after each page load. Alternatively, you can view the raw HTTP response from the server, waiting for it to send the set-cookie header or send the session identifier via GET or POST. Record the session identifier name and value as they appear, such as PHPSESSID=42656E2057616C74686572.

Clear your cookies for your site again. Issue a request to your application that contains the session identifier as part of the GET parameters. For instance, if you recorded the PHPSESSID mentioned above, you might enter: Click on a link within the returned page and then check your cookies again. If the session identifier uses the exact same value as you recorded earlier, then you have fixed your own session.

3.3. Description

Like other impersonation attacks, session fixation convinces the web application that the attacker and the victim are the same person. The key difference with session fixation is that session fixation requires that the target click a link, whereas session prediction or theft does not. However, given that grabbing session identifiers this way can be automated, such links may be mailed, updated, or otherwise distributed frequently enough that the chance of breaking in is not greatly diminished.

  •  Web Security Testing : Manipulating Sessions - Analyzing Session Randomness with WebScarab
  •  Web Security Testing : Manipulating Sessions - Analyzing Session Identifiers with Burp
  •  Programming .NET Security : Extending the .NET Framework (part 2) - Defining the Key Exchange Deformatter
  •  Programming .NET Security : Extending the .NET Framework (part 1) - Defining the Key Exchange Formatter
  •  Programming .NET Security : Programming Cryptographic Keys (part 3) - Key Exchange Formatting
  •  Programming .NET Security : Programming Cryptographic Keys (part 2) - Using Key Persistence
  •  Programming .NET Security : Programming Cryptographic Keys (part 1) - Creating Keys
  •  Deploying a Windows Server 2008 R2 Network Policy Server
  •  Understanding Network Access Protection (NAP) in Windows Server 2008 R2
  •  Programming .NET Security : Cryptographic Keys Explained
    Top 10
    Free Mobile And Desktop Apps For Accessing Restricted Websites
    MASERATI QUATTROPORTE; DIESEL : Lure of Italian limos
    TOYOTA CAMRY 2; 2.5 : Camry now more comely
    KIA SORENTO 2.2CRDi : Fuel-sipping slugger
    How To Setup, Password Protect & Encrypt Wireless Internet Connection
    Emulate And Run iPad Apps On Windows, Mac OS X & Linux With iPadian
    Backup & Restore Game Progress From Any Game With SaveGameProgress
    Generate A Facebook Timeline Cover Using A Free App
    New App for Women ‘Remix’ Offers Fashion Advice & Style Tips
    SG50 Ferrari F12berlinetta : Prancing Horse for Lion City's 50th
    - Messages forwarded by Outlook rule go nowhere
    - Create and Deploy Windows 7 Image
    - How do I check to see if my exchange 2003 is an open relay? (not using a open relay tester tool online, but on the console)
    - Creating and using an unencrypted cookie in ASP.NET
    - Directories
    - Poor Performance on Sharepoint 2010 Server
    - SBS 2008 ~ The e-mail alias already exists...
    - Public to Private IP - DNS Changes
    - Send Email from Winform application
    - How to create a .mdb file from ms sql server database.......
    programming4us programming4us