Team LiB
Previous Section Next Section


Passport authentication messages are passed in the form of electronic "tickets" that are used to inform the site that the user has signed in successfully. A ticket is a small amount of data that indicates the time the sign in occurred, when the user last manually signed in, and other information that is useful to the authentication process. Within the Passport system, these tickets take the form of cookies.

To obtain a ticket, a user with a Passport account signs in to the site or tries to access a protected Web page within the merchant site (e.g., a page that requires user authentication before allowing access). This redirects the user to a special page on This page takes information that the merchant site has appended to the URL and processes it. This allows the Passport service to know which merchant site has referred the user, and which merchant site to return the user to. Once the information has been processed, Passport redirects the user to a page on

Once the user enters their credentials, they are sent back to the domain. Once there and verified, Passport writes a cookie on the user's browser that stores information about this sign in. This is called a "ticket-granting-cookie" and it is used in subsequent sign in attempts. Then Passport redirects them back to your site.

When the user arrives back at the merchant site, they bring two encrypted packets of information attached to the query string. Software called the Passport Manager which is installed on the merchant's authenticating servers reads those packets and writes them as encrypted cookies in the merchant site domain.

The first cookie contains the authentication ticket information. The second contains any profile information that the user has chosen to share, and any operational information and unique identifiers that need to be passed. These packets are encrypted with a unique secret key that is shared between Passport and the merchant site. This helps to ensure that only the merchant can decode these messages.

The merchant site then takes this information and uses it to issue his cookies. Since these cookies are issued from the merchant domain, the merchant will have access to them. The merchant can use the Passport User ID to look a user up in the merchant database and perform authorization tasks.

When the user navigates to another Passport participating site, the new site has several choices to make about how they will authenticate this user. When the user clicks the sign in button, they are directed to the Passport service exactly as they were at their first sign in. The difference is that this time there is a ticket-granting-cookie saved on the browser that Passport can read.

Since the ticket contains the time that it was issued, it allows the referring site to decide how "fresh" the cookie needs to be in order for the site to accept it. If the ticket meets the rules the referring site has chosen, the user is redirected back to the referring site along with the encrypted ticket and profile cookies. If the ticket is too old, the user is prompted to re-enter their credentials.


However, passport has been plagued with security issues - right from reuse of authentication cache to privacy flouting activities. Apart from this exploits that plague Microsoft based web systems such as Unicode exploits, cross site scripting and cookie stealing cast more than a shadow of doubt on this means of authentication.

A few links exploring these issues are given below:

Conventionally, web applications had users authenticate themselves through a Web form. The user's credentials as captured by this form are submitted to the business logic which determines the authorization level. If the user is authenticated, the application generates a cookie or session variable. This cookie contains anything from a valid session identification access token to customized personalization values. The time period for which the cookie is valid or the contents stored in it are subject to security risks.

Forms Authentication is a system in which unauthenticated requests are redirected to a web form where the unauthenticated users are required to provide their credentials. In the context of ASP.NET, it extends similar logic into its architecture as an authentication facility, Forms Authentication. Forms Authentication is one of three authentication providers. Windows Authentication and Passport Authentication make up the other two providers.

Reverting back to the web based authentication method, on being properly verified by the application, based on the credentials input by the user, an authorization ticket is issued by the Web application in the form of a cookie. In essence, Forms Authentication is a means for wrapping the web application around the login user interface and verification processes.


Forms Authentication Flow

  • A client generates a request for a protected resource (e.g. a transaction details page).

  • IIS (Internet Information Server) receives the request. If the requesting client is authenticated by IIS, the user/client is passed on to the web application. However, if Anonymous Access is enabled, the client will be passed onto the web application by default. Otherwise, Windows will prompt the user for credentials to access the server's resources.

  • If the client doesn't contain a valid authentication ticket/cookie, the web application will redirect the user to the URL where the user is prompted to enter their credentials to gain access to the secure resource.

  • On providing the required credentials, the user is authenticated / processed by the web application. The web application also determines the authorization level of the request, and, if the client is authorized to access the secure resource, an authentication ticket is finally distributed to the client. If authentication fails, the client is usually returned an Access Denied message.

Click To expand

We have seen how digital certificates are used for authentication purposes. Typically, the administrator of a web site opts to provide secure communication through the SSL. To enable this, the administrator generates a certificate and gets it signed by a Certification Authority. The generated certificate will list the URL of the secure web site in the Common Name (CN) field of the Distinguished Name section. The CA verifies that the administrator legitimately owns the URL in the CN field, signs the certificate, and gives it back.

[CERT - Issuer: VeriSign / Subject: VeriSign] -> [CERT - Issuer: VeriSign / Subject:]


When a web browser receives the certificate, it should verify that the CN field matches the domain it just connected to, and that it is signed by a known CA certificate. No man in the middle attack is possible because it should not be possible to substitute a certificate with a valid CN and a valid signature. However, it is possible that the signing authority has been delegated to more localized authorities. In this case, the administrator of will get a chain of certificates from the localized authority:

[Issuer: VeriSign / Subject: VeriSign] -> [Issuer: VeriSign / Subject: Intermediate CA] -> [Issuer: Intermediate CA / Subject:]

When a web browser receives this, it should verify that the CN field of the leaf certificate matches the domain it just connected to, and also that it is signed by the intermediate CA, and that the intermediate CA is signed by a known CA certificate. Finally, the web browser should also check that all intermediate certificates have valid CA Basic Constraints.

Attack Methods 

However, as far as IE is concerned, anyone with a valid CA-signed certificate for any domain can generate a valid CA-signed certificate for any other domain. If an attacker wants to, he can generate a valid certificate and request a signature from VeriSign:

[CERT - Issuer: VeriSign / Subject: VeriSign] -> [CERT - Issuer: VeriSign / Subject:]

Then he can generate a certificate for any domain he wants to, and sign it using his CA-signed certificate: [CERT - Issuer: VeriSign / Subject: VeriSign]

-> [CERT - Issuer: VeriSign / Subject:] -> [CERT - Issuer: / Subject:]

Since IE does not check the Basic Constraints on the certificate, it accepts this certificate chain as valid for This means that anyone with any CA-signed certificate (and the corresponding private key) can spoof anyone else. Any of the standard connection hijacking techniques can be combined with this vulnerability to produce a successful man in the middle attack.


WinSSLMiM is an HTTPS Man in the Middle attacking tool. It includes FakeCert, a tool to make fake certificates. It can be used to exploit the Certificate Chain vulnerability in Internet Explorer. The tool works under Windows 9x/2000.


Example 1:

Generate fake certificate: fc -s -f fake_cert.crt

Launch WinSSLMiM: wsm -f fake_cert.crt

Example 2 (IE vulnerability):

Generate fake certificate: fc -s -f fake_cert.crt -t trust.crt

Launch WinSSLMiM: wsm -f fake_cert.crt -t trust.crt

Passwords are the principal means of authenticating users on the Web today. It is imperative that any Web site guard the passwords of its users carefully. This is especially important since users, when faced with many Web sites requiring passwords; tend to reuse passwords across sites. Compromise of a password completely compromises a user.

Attack Methods 

Often Web sites advise users to choose memorable passwords such as birthdays, names of friends or family, or social security numbers. This is extremely poor advice, as such passwords are easily guessed by an attacker who knows the user. The most common way an attacker will try to obtain a password is through the dictionary attack'. In a dictionary attack, the attacker takes a dictionary of words and names, and tries each one to see if it is the require password. This can be automated with programs which can guess hundreds or thousands of words per second. This makes it easy for attackers to try variations: word backwards, different capitalization, adding a digit to the end, and popular passwords.

Another well-known form of attack is the hybrid attack. A hybrid attack will add numbers or symbols to the filename to successfully crack a password. Often people change their passwords by simply adding a number to the end of their current password. The pattern usually takes this form: first month password is "site"; second month password is "site2"; third month password is "site2"; and so on. A brute force attack is the most comprehensive form of attack, though it may often take a long time to work depending on the complexity of the password. Some brute force attacks can take a week depending on the complexity of the password.

The common passwords used are: root, administrator, admin, operator, demo, test, webmaster, backup, guest, trial, member, private, beta, [company_name] or [known_username]


Webcracker allows the user to test a restricted-access website by testing id and password combinations on the web site.

This program exploits a rather large hole in web site authentication methods. Password protected websites may be easily brute-force hacked, if there is no set limit on the number of times an incorrect password or User ID can be tried.

WebCracker is a simple tool that takes text lists of usernames and passwords and uses them as dictionaries to implement Basic authentication password guessing.


Brutus is an online or remote password cracker. More specifically it is a remote interactive authentication agent. Brutus is used to recover valid access tokens (usually a username and password) for a given target system. Examples of a supported target system might be an FTP server, a password protected web page, a router console a POP3 server etc. It is used primarily in two ways:

  • To obtain the valid access tokens for a particular user on a particular target.

  • To obtain any valid access tokens on a particular target where only target penetration is required.

Brutus does very weak target verification before starting; in fact all it does is connect to the target on the specified port. In the context of Brutus, the target usually provides a service that allows a remote client to authenticate against the target using client supplied credentials. The user can define the form structure to Brutus of any given HTML form. This will include the various form fields, any cookies to be submitted in requests, the HTTP referrer field to send (if any) and of course the authentication response strings that Brutus uses to determine the outcome of an authentication attempt.

If Brutus can successfully read forms of the fetched HTML page then each form will be interpreted and the relevant fields for each form will be displayed. Any cookies received during the request will also be logged here. Brutus handles each authentication attempt as a series of stages, as each stage is completed the authentication attempt is progressed until either a positive or negative authentication result is returned at which point Brutus can either disconnect and retry or loop back to some stage within the authentication sequence.


ObiWaN stands for "Operation burning insecure Web server against Netscape". It is called Project 2086 now, after 2068 the number of the RFC which describes the HTTP/1.1 protocol. 11.1 is the section which describes the basic authentication scheme. This is the mostly used authentication scheme for web server and used by ObiWaN.

Web servers with simple challenge-response authentication mechanism mostly have no switches to set up intruder lockout or delay timings for wrong passwords. Every user with a HTTP connection to a host with basic authentication can try username-password combinations as long as he/she like it. This allows the attacker to prod the system as long as he wants to.

Like other programs for UNIX system passwords (crack) or NT passwords (lophtcrack) ObiWaN uses wordlists and alternations of numeric or alpha-numeric characters as possible passwords. Since web servers allow unlimited requests it is a question of time and bandwidth to break in a server system. The first way is to run ObiWaN more than once. The following example tries to crack username eccouncil on the intranet.

     ./ObiWaN -h intranet -a eccouncil -w list.txt

To run it with alphanumeric variation with a depth of 2

     ./ObiWaN -h intranet -a eccouncil -w list.txt -A 2

To run it in brute force loop mode

     ./ObiWaN -h intranet -a eccouncil -w list.txt -b 6 -B 8


Munga Bunga's HTTP Brute Forcer is a utility utilizing the HTTP protocol to brute force into any login mechanism/system that requires a username and password, on a web page (or HTML form). To recap - A password usually only contains letters. In such a case the quantity of characters in a charset is 26 or 52, depending on usage of registers - both of them or just one. Some systems (Windows, for example) don't make any difference between lower-case and uppercase letters. With an 8-characters' long password the difference would amount to 256 times, which is really significant.

Brute force method can sometimes be very effective when it is combined with the functionality of the program. Munga Bunga is a tool which can be used for breaking into emails, affiliate programs, web sites, any web based accounts, launching DoS attacks, flooding emails, flooding forms, flooding databases and much more; though DoS attacks and flooding activity are not supported or documented in the documentation. Apart from this, the attacker can write definition files. These are files ending in the .def extension, and contain information about a particular server, and the data to submit to it. They are used to extend the power and capability of the program, based on the user's own definitions. The software comes bundled with some definition

The tool claims to be capable of brute forcing, any thing that can be entered via a HTML form with a password and username. The attack methodology goes as follows: The attacker uses a password file in order for the program to attempt and enter the account(s), with the specified passwords. In addition, he can write a definition file for the form he wants to crack into.

Crackers can use readymade word dictionaries available on the Internet or use dictionary compiling programs to make word lists that can be used for password cracking.


Dictionary Maker is a tool to compose dictionaries (word lists) using multiple source text files. Dictionary Maker extracts all words from source text files and put them into output dictionary. Any duplication is eliminated. The program is optimized for speed and could be used to compose really big dictionaries.

The buttons for the work with the dictionary are on the 'Dictionary' panel.

The 'Status' panel displays the present state of the dictionary, as stored in the memory.


Passlist is a character based password generator that implements a small routine which automates the task of creating a "passlist.txt" file for any brute force tool. The program does not require much information to work. The tool allows the user to specify the generation of passwords based on any given parameter. For instance, if the user knows that the target system's password starts with a particular phrase or number, he can specify this. This makes the list more meaningful to the user and easier for the brute forcer. He can also specify the length required such as the maximum number of random characters per password, apart from the maximum number of random characters per password. That is all there is to generate a password list. There are several other tools.


A partial list is given below.

  • Refiner is used to generate a wordlist containing all possible combinations of a partial password, which an attacker may have obtained by other means. Refiner will then generate a text file containing all possible combinations.

  • WeirdWordz allows the user to just select an input file and as an output file, makes all sorts of combinations of the lines/words in the input file.

  • Raptor 1.4.6 - creates words using many different filters from html files to create a wordlist.

  • PASS-PARSE V1.2 - Pass-parse will take any file and turn all the words into a standard type password list, while stripping anything that's not alphanumeric. The main idea behind it is that while trying to crack the password of a personal website, the password may appear on the site when the person describes their interests. This will parse through an html file and create a list of words from that page to try as passwords.

Parameter Manipulation is a class of attack where the malicious user is able to manipulate data being sent between the web browser and the web server (and consequently back to middle-ware / back-ends) to his or her advantage. Traditionally Parameter Manipulation is referred to as manipulating query strings but any data such as cookies and form fields should be considered. When a user makes selections on an HTML page, they are typically stored as form field values and sent to the application as an HTTP request (GET or POST). Despite GUI selections, the user can choose to send whatever parameter values he/she chooses by constructing a request string of his choosing. The command sends the following HTTP request.

Attack Methods 

A malicious user could construct a fraudulent account number and change the parameters as follows:

The new parameters would be sent to the application and be processed accordingly. There are several ways of preventing this sort of attack, but all essentially work by coupling the parameters being passed to the application with the users account via some form of "session token". This is usually done by creating an encrypted session token that cannot be changed by the user. Each time parameters are passed to the application, it checks to see if the session token is valid. Another technique is to encrypt a parameter (the session token) on the query string and require it to be re-submitted with the request.

Attack Methods 

Query strings in browsers are easily modifiable since the query string is visible in Browser's location bar. However, the POST method does not display post data. To change the value of posted data an attacker can choose to first save the HTML page, modify the HTML source and then POST the fraudulent request to the server.


"curl[4] is a tool for transferring files with URL syntax, supporting FTP, FTPS, HTTP, HTTPS, GOPHER, TELNET, DICT, FILE and LDAP", as stated on its home page at More precisely, curl is a portable command-line executable for convenient Web retrieval, along with an associated library, libcurl. In 1997, Daniel Stenberg, a consultant based just north of Stockholm, wanted to make currency-exchange calculations available to Internet Relay Chat (IRC) users. All the necessary data are published on the Web; he just needed to automate their retrieval. He simply adopted an existing command-line open-source tool, httpget, which Brazilian Rafael Sagula had written.

Original curl users primarily wanted it for straightforward automations that they launched from simple shell scripts. Lately, developers have been binding libcurl's C-coded functionality to a variety of other languages.


To ftp files using name+passwd, include them in the URL like: curl -u name: passwd ftp://machine.domain:port/full/path/to/file

The HTTP URL doesn't support user and password in the URL string. Curl does support that anyway to provide a ftp-style interface and thus you can pick a file like:

curl -u name: passwd http://machine.domain/full/path/to/file you must use the -u style fetch while using with a proxy.

The name cookie derives from UNIX objects called magic cookies. These are tokens that are attached to a user or program and change depending on the areas entered by the user or program. Cookies are small data structures used by a web site (server) to deliver data to a web client (user); request that the client store the information; and in certain circumstances, return the information to the web site. Web sites can thus "remember" information about users to facilitate their preferences for a particular site and allow the use of user passwords. The web site may deliver one or more cookies to the client. The client stores cookie data in one or more flat files on its local hard drive.


Cookies have six parameters that can be passed to them:

  • The name of the cookie. The value of the cookie. The expiration date of the cookie - this determines how long the cookie will remain active in the browser.

  • The path the cookie is valid for - this sets the URL path the cookie use valid in. Web pages outside of that path cannot use the cookie.

  • The domain the cookie is valid for. This makes the cookie accessible to pages on any of the servers when a site uses multiple servers in a domain.

  • The need for a secure connection - this indicates that the cookie can only be used under a secure server condition, such as a site using SSL.


Cookie Spy is a little utility that will not only display but also lets the user delete the cookies that are not required. It will list all the cookies on the computer, the date and time they were created and a link directly to the website that put them there. Using the update option shows the expiration date and life of the cookies.

A simple code that can be used on WebPages to read cookies of the visitor is shown below.

         String cookieName = "Username";
         Cookie cookies [] = request. getCookies ();
         Cookie myCookie = null;
         if (cookies != null)
                for (int i = o; i < cookies.length; i++)
                         if (cookies [i].getName().equals (cookieName))
                                     myCookie = cookies[i];

Of course, it goes without saying that this innocent code can do more than read cookies. It can also be used to steal or hijack cookies.


Snadboy's Revelation can be used to unmask the masking character - the asterisk - seen when a user enters a password on a web form. While this can be user to "remember" a stored password, the downside is that it need not be the owner of the password who does the remembering part.

Click To expand

[4]Source: "Regular Expressions: curl Simplifies Web Retrieval" by Cameron Laird and Kathryn Soraiz

Team LiB
Previous Section Next Section