Advance XSS Attacks, DOM Based

 

Robert ‘rsnake’ Hensen is considered as Guru of XSS. Let’s learn advance DOM based attack from his own book “XSS attacks: cross-site scripting exploits and defense”
Preview of his book is available at http://books.google.com/books?id=Imt5Crr0jJcC

DOM-based is unique form of XSS, used very similarly to non-persistent, but where the JavaScript malware payload doesn’t need to be sent or echoed by the Web site to exploit auser. Consider our eCommerce Web site example (Figure 1.1.), where a feature on the Website is used to display sales promotions.The following URL queries the backend database for the information specified by the product_id value which is shown to the user. (Figure 1.2)

To make the user experience a bit more dynamicity, the title value of the URL’s can be updated on the fly to include different impulse-buy text

http://victim/promo?product_id=100&title=Last+Chance!http://victim/promo?product_id=100&title=Only+10+Left!

Etc.

The value of the title is automatically written to the page using some resident JavaScript.

This is where the problem is. In this scenario, the client-side JavaScript blindly trusts the data contained in the URL and renders it to the screen.This trust can be leveraged to craft the following URL that contains some JavaScript malware on the end.

http://victim/promo?product_id=100&title=Foo#

As before, this URL can be manipulated to SRC in additional JavaScript malware from any location on the Web. What makes this style of XSS different, is that the JavaScript malware payload does not get sent to the Web server. As defined by Request For Comment (RFC), the “fragment” portion of the URL, after the pound sign, indicates to the Web browser which point of the current document to jump to. Fragment data does not get sent to the Web server and stays within the DOM. Hence the name, DOM-based XSS.

Persistent (or HTML Injection) XSS attacks most often occur in either community contentdriven Web sites or Web mail sites, and do not require specially crafted links for execution.A hacker merely submits XSS exploit code to an area of a Web site that is likely to be visited by other users.These areas could be blog comments, user reviews, message board posts, chat rooms, HTML e-mail, wikis, and numerous other locations. Once a user visits the infected Web page, the execution is automatic.This makes persistent XSS much more dangerous than non-persistent or DOM-based, because the user has no means of defending himself. Once a hacker has his exploit code in place, he’ll again advertise the URL to the infected Web page, hoping to snare unsuspecting users. Even users who are wise to non-persistent XSS URLs can be easily compromised.

DOM is a World Wide Web Consortium (W3C) specification, which defines the object model for representing XML and HTML structures. In the eXtensible Markup Language (XML) world, there are mainly two types of parsers, DOM and SAX. SAX is a parsing mechanism, which is significantly faster and less memory-intensive but also not very intuitive, because it is not easy to go back to the document nodes (i.e. the parsing mechanism is one way). On the other hand, DOM-based parsers load the entire document as an object structure, which contains methods and variables to easily move around the document and modify nodes, values, and attributes on the fly.

Browsers work with DOM. When a page is loaded, the browser parses the resulting page into an object structure.The getElementsByTagName is a standard DOM function that is usedto locate XML/HTML nodes based on their tag name. DOM-based XSS is the exploitation of an input validation vulnerability that is caused by the client, not the server. In other words, DOM-based XSS is not a result of a vulnerability within a server side script, but an improper handling of user supplied data in the client side JavaScript. Like the other types of XSS vulnerabilities, DOM-based XSS can be used to steal confidential information or hijack the user account. However, it is essential to understand that this type of vulnerability solely relies upon JavaScript and insecure use of dynamically obtained data from the DOM structure.

Here is a simple example of a DOM-base XSS provided by Amit Klein in his paper “Dom Based Cross Site Scripting or XSS of the Third Kind”:

Hi


Welcome to our system…

If we analyze the code of the example, you will see that the developer has forgotten to sanitize the value of the “name” get parameter, which is subsequently written inside the document as soon as it is retrieved. In the following section, we study a few more DOM based XSS examples based on a fictitious application that we created.

Let’s walk through the process of identifying DOM-based XSS vulnerabilities using a fictitious Asynchronous Javascript and XML (AJAX) application.

First, we have to create a page on the local system that contains the following code:

Awesome

awesome ajax application

Please, enter your nick and presschat!

Awesome AJAX Application

Next, open the file in your browser (requires JavaScript to be enabled).The application looks like that shown in Figure 1.3

Once the page is loaded, enter your name and press the Chat button.This example is limited in that you cannot communicate with other users.We deliberately simplified the application so that we can concentrate on the actual vulnerability rather than the application design. Figure 1.4 shows the AJAX application in action.

Notice that this AJAX application does not need a server to perform the desired functions. Remember, you are running it straight from your desktop. Everything is handled by your browser via JavaScript and jQuery.

** jQuery is a useful AJAX library created by John Resig. jQuery significantly simplifies AJAX development, and makes it easy for developers to code in a cross-browser manner.**

If you carefully examine the structure and logic of the JavaScript code, you will see that the “Awesome AJAX application” is vulnerable to XSS.The part responsible for this input sanitization failure is as follows:

$(this).html('

Welcome ' + name + '! You can type your message into the formbelow.

');

As seen, the application composes a HTML string via JQuery’s HTML function.The html function modifies the content of the selected element.This string includes the data from the nickname input field. In our case, the input’s value is “Bob.” However, because the application fails to sanitize the name, we can virtually input any other type of HTML, even script elements, as shown on Figure 1.5

If you press the Chat button, you will inject the malicious payload into the DOM.This payload composes a string that looks like the following:

Welcome

! You can type your message into the form below.

This is known as non-persistent DOM-based XSS. Figure 1.6 shows the output of the exploit.

Credits : Rsnake, Article already published in Rsnake's Book

Network Attacks

Any method, technique or process used to attack and compromise the security of the network can be termed as a Network attack. There can be a number of motives behind the attacks like fame, terrorism, greed, etc.  A few types of various malicious attacks are covered in this article.

The common and popular attacks would be

EavesdroppingDenial-of-ServiceSession HijackingIP SpoofingDNS SpoofingMan-in-the-Middle Attack

Eavesdropping is basically the act of secretly listening to the conversation of others, obviously without their permission. This definition can also be applied to network sniffing. In network sniffing, attacker secretly sniffs/listens to the data transmitted thorugh the network. The modules operating would be like this -

A machine is configured to “listen” mode and then it is used to capture the juicy data from the network! This can be done using readily available programs like Cain and Abel, Ehtercap, SSLsniff, etc. 

Wikipedia - A denial-of-service attack (DoS attack) is an attempt to make a computer resource unavailable to its intended respondents. It generally consists of the concerted efforts of a person or people to prevent an Internet site or service from functioning efficiently or at all, temporarily or indefinitely.

Smurf Attack

These attacks can be destructive. In this attack, an attacker sends a large amount of ICMP echo (ping) traffic at IP broadcast addresses. These packets have spoofed IP address of the source pointing to the victim. To amplify the attack several intermediary sites are selected by the attacker. This results in lots of ping replies (ICMP echo Reply) and thus resulting in victim being compromised.

SYN Flood attack

SYN flood attacks exploits TCP three-way handshake.  In this attack, attacker sends lots of TCP SYN packets to the victim with spoofed source IP address. These packets try to establish connection with the victim. Now what happens is that the victim sends back a TCP SYN-ACK packet and waiting for the response from the source. But as the source address is spoofed the response never comes thus creating half open connections.

This floods the available connection with the server and in the process keeps the server from responding to legitimate traffic.
This flooding if done in large volume can cause DoS.

Distributed Denial-of-service (DDoS) Attack

In DDoS attack, the attacker compromises large number of computers, mostly in different locations. These compromised machines are called as secondary victims or Zombies. Then these zombies are used as attack platform to attack the primary victim.
The zombies or the secondary victims may not be aware that they are being used to attack the primary victim. Trojans and viruses give the control attacker to these machines to launch attacks of the victim.

This attack is difficult to detect as the attack comes from several IP address. This is the most deadly attack of all and not easy to overcome. 

Session hijacking exploits computer session between two machines. Here, computer session means connection between two machines.

When a TCP session is established a cookie is used to verify if the session is active or not. The attacker can steal these cookies by sniffing or using the saved cookies on victim’s computer. Since most of authentication is done only at the start of the session, this allows the hacker to assume the identity of the victim and gains the same access to the resources as that of the victim.

Types of Session Hijacking attacks
1.    Active
2.    Passive

In an Active attack, attacker hijacks an existing session on the network by doing a Man-in-the-middle attack.  This allows the attacker to execute a various commands in order to maintain his access, delete the traces etc. The attacker can create accounts on the network which can be used to gain access later without having to do session hijack every time.
In Passive attack, attacker monitors the ongoing session in the network. This attack uses sniffer tools to sniff around the network and find juicy information!

The third type, Hybrid attack, uses the combination of the above mentioned attacks. This attack is used to sniff and modify the data simultaneously.

IP spoofing, also known as IP address forgery, is a technique that replaces the original IP address with another machine’s address  in which an attacker impersonates as a trusted host to conceal his identity, spoof a Web site, hijack browsers, or gain access to a network.

Here's how it works: The attacker obtains the IP address of a legitimate host and alters IP packet headers so that the legitimate host appears to be the source. So now when a visitor types in a URL of a legitimate site, he is taken to a fraudulent web page created by the attacker. For example, if the attacker has spoofed a site, say www.abc.com, then any visitor who types this in the URL  would see spoofed content created by the attacker instead of the original content.

With this kind of attack, the attacker could gain access to juicy information such as passwords, credit cards numbers, etc or install malware or alter the data.

Domain Name Service (DNS) basically transforms a domain name, (say www.example.com) to its IP address (say 11.22.33.44). AND DNS spoofing is a technique where in a DNS entry to point to another IP rather than it is supposed to point to.
There are two methods of DNS spoofing:-

1.    DNS Cache Spoofing: - DNS server cannot store information about all existing domain names and IP addresses in its cache. It is done to avoid constant repetitions of inquiries to login to servers of corresponding domains.

Now data is introduced into a DNS name server's cache database that did not originate from authoritative DNS sources. Its maliciously crafted attack on the name server. It may also result from improper software design of DNS applications.

The second variant of the attack directed on substitution DNS, consists in change of a server cache DNS.

2.    DNS ID spoofing:- The heading of a package of the DNS-protocol contains an identification field for conformity of inquiries and answers. The purpose of substitution DNS ID is to send the answer to DNS-inquiry before the present DNS-server will answer. For performance of it, it is necessary to predict the identifier of inquiry. Locally it is realized by simple listening of the network traffic.

In Man-in-the-Middle (MITM) attack, the attacker intercepts the traffic between two machines and make the victims believe that they are talking directly to each other, when in fact their conversation is controlled by the attacker.

The attacks starts with sniffing and eavesdropping and after the attacker gains access to the conversation, he can extract juicy information like passwords, credit cards numbers, etc. or can alter the data, install malwares.

JSON XSRF Attacks

Welcome to another episode of Cross Site Request Forgery Attacks on DEVILS BLOG ON SECURITY. In this post we will discus a little about JSON hacking. Now you might have question why we haven't covered JSON XSRF attacks along with other XSRF attacks. This question is little difficult to answer but here's my explanation. All other XSRF attacks usually depend on session management attacks in one or another way, directly or indirectly XSRF attacks can be called as derivative obtained by adding and integrating Session Management Attacks, Frame Injection Flaws and Cross Site Scripting whereas the case is little different in JSON XSRF attacks. Many professionals even object inclusion of JSON attack as XSRF attack but we have nothing to do with it. So lets see how JSON XSRF attacks are different from other XSRF attacks.
All modern web browsers implement Same Origin Policy (SOP) on website content. This policy avoids one website from writing contents of frame that was issued from different domain. This policy was implemented against Frame Injection flaws. JSON CSRF exploits SOP by lifting one way restriction on website and allows data from another website to execute on different domain. This vulnerability is result of flaw in SOP which treats JavaScript as code and not data. According to browser policy a code is allowed to get downloaded and execute over a client browser though original source of script is different. Full form of JSON is Java Script Object Notification which is a data transfer format for JavaScript interpreters. It is used in AJAX based applications as an alternative to standard XML data transfer format. In these applications requests are made using XMLHttpRequest to server and server returns data in JSON format. The received data is proceed on client side. Since JavaScript is used to transmit data than pure code SOP policy can get exploited to gain data generated by other applications. This data is transmitted back in form of an array. Thus due to JSON an XSRF attack can be easily executed on vulnerable site. From above discussion its quite clear JSON CSRF attacks can be implemented over a AJAX based website which uses JSON data transfer format against standard XML data transfer format. Surely this topic is little wild to understand for those who don't know JavaScript, AJAX and XML. By the way in next post we'll see how to find vulnerability and execute attack using JSON format till then thanks for reading, have a nice time and keep visiting.

Session Hacking | Session Management Attacks | The Basics

So we are here to discus one more topic related to web application hacking, that is session hacking. Note that session hijacking and session hacking are closely related terms but are slightly different. In session hacking application level attacks are concerned where as in session hijacking application level attack as well as TCP/IP level attacks are covered. Session hacking in other terms can also be called as Session Management Attack. So here I must clear we are discussing session hacking not session hijacking. People with confusion in session hacking and session hijacking should read this post carefully I hope that would help them clear up their confusion. So first of all what is session, session can be termed as an entity which is responsible for handling your state over internet like whether you are logged in or not or which item you have added to your cart while shopping etc. And most common and well known method known for managing sessions are cookies.
Web applications become vulnerable to session hacking due to improper generation and mishandling of cookies while undergoing process. The data that is passed as cookie is known as token so in fact we can say that weak token generation methods and weakness in handling them is main reason for session getting hacked. What are common weak token generation methods ?One of the most common mistake many new web developers make is they design tokens to be meaningful. That means most likely the token is created from user-name, password, email id, telephone or mobile number, country, region, time and similar information about logged user. And if token does not include password there is 100% chance that hacker can log in as any user he/she wants since all other information is readily available in user's profile to create a new legal tokens as cookie values. Next weak token generation method may include generation of token value that is predictable. Predictable token can be generated in several ways for example creating a pattern to generate token, using only hexadecimal values, using known token generation methods, using hidden sequences while generating tokens. Lastly creating a session token which is fully time independent or fully time dependent. One of the biggest mistake that can be done while creating tokens for handling session. In fact many experienced hackers might even crack token generated using this method in few minutes. It's never a good idea to use this method for generating tokens. What are common token mishandling methods ?The very first in list is coding for cookies in improper way to work in LAN network. Next is appearance of tokens in session logs and URL.And third is storing cookies in wrong way.Lastly thinking that we have implemented SSL means we are secure to session related attacks.A session token vulnerable to attack means complete session is vulnerable to attack. Underestimating session handling can prove to be serious. So here we end up with basics of session hacking in next post we will have our look on how to perform session hacking attack against weak cookie generation and then in next post to it how to perform attacks on token mishandling methods and lastly how to perform hacked session CSRF attack. Till then thanks for reading, have a nice time and keep visiting.

SSL And TLS Attacks | Weak Ciphers

Both SSL and TLS protocols works on the basis of Public Key Infrastructure (PKI) and commonly includes key exchange algorithm to handle security. Apart from just CA authority the strength of SSL cipher depends on length of key, encryption algorithm used to encipher data and Message Authentication Code (also known as SSL MAC). In this post we will have our look on how key length could effect on cipher strength. So depending on the length of initial key generated for data exchange during SSL and TLS communication, ciphers can be divided into following categories.
As name suggests these ciphers do not provide any security since there's no encryption.All ciphers with key length less than 128 bits fall under this category. Ciphers using Diffie Hellman algorithm for key exchange are also considered as weak security ciphers since they are vulnerable to man-in-the-middle-attack.Ciphers with key length more than 128 bits and less than 256 bits are considered as strong security ciphers.Keys in this ciphers use 256 bit keys with AES encryption. These are considered as highly secured and used by high octane organizations and research institutes.As discussed in our previous post ciphers are actually decided with the help of Cipher suites defined to encipher data. At present there are more than 30 different cipher suites used to encipher data out of which only following are considered as secure.Rest all are classified under weak cipher suites. Each and every initial after hyphen represents an encryption algorithm for cipher suite. Dangers Posed By Weak Ciphers:The attacker can interrupt communication between client and server and downgrade connection to use HTTP instead of HTTPS. This can be done by ARP poisoning and using SSL strip by Moxie Marlin Spike.The attacker can use hardware protocol analyzer to capture packets directly from wire and then decipher them.If attacker is well knowledged with application and its working, he can actually code another program to change meaning of messages transferred during communication.Tools That Can Be Used To Detect Weak Ciphers:Foundstone SSL Digger and THC SSL Check are two awesome tools that can be used to check SSL cipher strengths. Both are easy install and go tools. Just input site name and they'll analyze site for weak SSL ciphers. Countermeasures Against Weak SSL Cipher Attacks:The best way to counter weal SSL Cipher attacks is to disable them. Check your server's how to or help pages to disable weak ciphers.

Attacks Against Weak Token Generation

During our last post to this we discusses about basics of Session Management Attack which is also known as session hacking. In this post we will have a look on how you can attack weak token generation method to attack session management. Following are most common methods of generating weak tokens,Adding time dependent variations in tokens
Now some important things before we discus real hack steps. In applications that use standard cookie mechanism for transmitting session tokens, it is easy to identify which item of data contains the token. In other cases it needs real brain work to identify them. Many web developers add extra tokens to cookies to fool hackers for example an application might add 14 tokens to yours browser's store, out of which only six are responsible for session management no matter what value other eight have only six of them will handle session. An application may apply several different items of data collectively to implement as token including, cookies, URL parameter, hidden form filed and even stored IP addresses. So it is important for a hacker to keep an eye on each of them while implementing hacking steps. Tools that are required for session hacking are Mozilla Firefox web browser and Add N Edit addon to it. First of all log-in to your account several times a day and copy cookie parameters in a text file, for each time you logged also note down time, changes in URL and hidden values.Next step would be finding out which tokens are really useful for session handling and which one are for fooling. So log in once again copy original cookie values and try to alter value for each token. If you were unable to log-on or you got logged in as another user after altering a token then that is the token useful for you. Try same on all tokens.Last step would be identifying what is weakness in tokens, sorry that can't be done using tool it requires you some brain-work.So after identifying which type of weakness a token has we will craft our attack against them. Suppose you logged in with,and tokens generated includes values like following,u_u=36e672d41e98209fa80b34375d4316bdpd_=c521b8e207540b324f6beeb34157b47bthen its not difficult to identify that the above tokens are nothing but MD5 hashes. The hacker will have no problem identifying it no matter it is salted or not. Other weakness like predictable tokens and time dependent variations in tokens are difficult to find out. Usually no developer ever uses easy predictable and time dependent variations in tokens. If anyhow you were able to detect them manually then it surely gives you an idea about qualification and experience of developer who has implemented those tokens in cookies. To detect them Burp Intruder a tool from Burp Suite is used. Burp suite is an application that can used be to audit and attack web applications. Burp suite is developed by Port Swigger Web Security and is available for download in both free and paid versions. Without any doubt burp suite is best web application scanner and can scan and detect weakness and vulnerabilities more than what I have so far ever discussed on my blog regarding session management. Download burp from following link.Interface of Burp Suite is self explanatory so you'll hardly face any problem using it. By the way in future posts we will surely discus more about Burp Suite and various tools it have for web application scanning.So here we complete attacks against weak token generation, in next post to this we will cover attacks against mishandling of tokens. Till then thanks for reading have a nice time and keep visiting.

Attacks Against Mishandling Of Tokens

In last post to session hacking series we saw how to attack weak token generation methods. In this post we will see how session tokens are mishandled and how they are attacked for mishandling. An important point that you must note that no matter how much secure coding you implement while creating session tokens if they are mishandled there's no way you can protect session from getting hacked. Next thing that you should keep in mind is that implementation of SSL doesn't guarantee 100% security against session hacking. Implementation of SSL helps in protecting tokens if implemented properly but honestly speaking there are many websites which does not really implement SSL properly thus leaving even SSL open to attack.
Attacks Against Disclosure Of Tokens On Network:This is really damn big problem which is proof of the concept SSL can be wrongly implemented. Following are some real world examples of such faulty implementation,Facebook uses HTTPS to protect user's credentials while logging in but turns back to HTTP after logging in thus credentials are made safe but not the session tokens. Reality is that those token are transmitted every-time when page is changed or reloaded thus leaving session tokens readily available for sniffing. Any packet sniffing tool for example wireshark, ettercap, dsniff, Cain And Abels, Ace Sniffer etc can be used for attacking such disclosure over network. Read our post how to hack facebook password using wireshark to get real idea bout how attack is performed on this foolish implementation.You may have noticed several websites on which when you arrive at log-in page you see HTTP in URL but when you press log-in it tries to switch to HTTPS. If an attacker positioned properly between user and website he/she can downgrade such connection completely to use HTTP to reveal session tokens over network or simply he/she will modify victim's browser to use only HTTP. Attack on such connection can be made using Ettercap and SSL strip.A website using both HTTP and HTTPS connection simultaneously is also vulnerable to attack.In all any kind of wrong SSL implementation can be attacked using Packet sniffer.Attacks Against Disclosure Of Tokens In Logs:Several websites show token logs in their URL while browsing, for example consider following example,http://www.victimsite.com/log;jsessionid=F27ED2A6AAE4C6DA409A3044E79B8B48?category=765as you can see the session id is highly visible. Though this visibility might be for fraction of seconds while logging in but is highly vulnerable. This type of token visibility makes session vulnerable even though HTTPS is implemented but the major problem it faces that it is not only visible to one user it is visible to everyone. This vulnerability can be attacked using Burp Suite. All you have to do is intercept session from URL and try to alter it to hijack session.Attacks Against Improper Storage Of Cookies:By default many websites save cookies in default path in web browser i.e ' / '. That leaves tokens open to get detected by hacker. For example suppose you visit www.vulsite.com/page1/page2/app.jsp then cookies will be set to domain www.vulsite.com and to path /page1/page2/ of your web browser. Since all cookies will be directly set to default path they become vulnerable to get stolen and that's why cookie stealer are able to retrieve cookies from your web browser since path is already known. By the way we will cover how different types of cookie stealer are made some other day but for now keep in mind improper storage of cookies can be attacked using cookie stealer. So in next post to this we will see countermeasures that can be implemented against session hacking. Till then thanks for reading have a nice time and keep visiting.

SSL And TLS Attacks | SSL Man In The Middle

In our last post we discussed a little about attacking weak ciphers in this post we will have our look on how a Man In The Middle (MITM) attacks can be performed over SSL and TSL encrypted data transfer. The attack uses SSL strip developed by Moxie Marlin Spike with a ARP spoofing tool and a packet sniffer. The attack can be exclusively performed from UNIX and Linux based platforms hence I suggest you to use Dsniff. Practically SSL strip was developed to demonstrate how an attacker can lead visitors to visit his/her site from legitimate site. The attack used misinterpretation of null characters vulnerability which existed in several certificates during 2009.
I think its not good to demonstrate how attack can be performed since Moxie Marlin Spike has already provided a nice tutorial on his own website with a video. Here we gonna discus scene behind attack means why this attack is possible. Following figure demonstrates what happens when your data gets encrypted before it reaches its destination.
As you can see first of all your data goes to the CA authorities (SSL provider) for verification and then actual key exchange takes place, the scenario remains as it is even in LAN. Therefore if an attacker manages to fake out as CA authority it can sniff encrypted connection. First the attacker needs that all traffic in network should pass from his/her system.So he/she performs ARP poisoning attack. (for more info on ARP poisoning read Packer Sniffer section).Now he/she installs SSL strip in his/her system with respect to access point of network. By doing so attacker manages to act as CA authority for all traffic that will pass from his/her system.When victim tries to connect remote system using SSL connection. It asks for trust from a CA authority and when it asks for trust to authority, SSL strip (which is installed in attacker's system) manages to reply with positive response. The SSL strip grants permission for connection using null-termination certificate and it guarantees attacker that the connection will just appear as HTTPS but all data transfer will be done using HTTP. Note that connection would be HTTPS but work as HTTP since null certificate does not provide any security and attacker will successful sniffing packets from SSL connection.The best countermeasure I can suggest over this kind of attack is installing anti-sniffing and arp spoofing detection tools. And for clients in LAN never ever trust any connection that you would be making from your LAN network.I think that's it for SSL and TLS attacks for this post. In our next post we will discus more about vulnerability due to outdated MD-2 encryption, till then have a nice time and keep visiting.

Session Management Attacks Countermeasure

From last few posts we are discussing session hacking or we can say attacks against session management. So after having a small look over session hacking and some of its regular types its time to have a look on its countermeasures. Same as any other web application countermeasures session hacking countermeasures also depend upon type of application and its implementation or you can say type of vulnerability a web application can suffer from. In this following post we will discuss some preventive measures which can be practically implemented over any web application against session hacking.

Following are some tips to generate strong tokens for protecting sessions against predictable token vulnerability.Check each value for randomness before implementing in session management.Make sure token's complexity can't be broken using brute force, so use real large values with possible random characters.Never use weak hashes, hexadecimal values, octal values or something like that which generates predictable values for token generation.Don't use time dependent variables to generate token.Tokens should consist of nothing more than an identifier used by the server to locate the relevant session object to be used for processing the user’s request and make sure there should be enough number of tokens so that it should not be easy for anyone to attack.Token generation method should be different for each token.Now information that can be used to generate tokens,Port number from which user sent request.User's browser protocol or User Agent details.Absolute time of request in milliseconds.Now why above things can be used for generating tokens though they can be predictable. The reason is we are not actually advising you to use any one of them we are advising you to use each of them, by doing so you'll be able to generate a token which will be highly unpredictable and due to time of request you can manage to terminate session after some specific interval of time.Protecting Tokens From Mishandling:Following are some measures that should be taken on behalf of developer against mishandling of tokens.All tokens should be passed from HTTPS and not from HTTP.A page must not use HTTPS and HTTP simultaneously.If possible all pages should be implemented using HTTPS including static and help pages. Use HTTPS for all pages rather than switching from HTTP to HTTPS for specific pages since it can act as vulnerability which can help attacker to steal session.Session log should never be transmitted in URL.Session token should die after some specific interval of time (10 min - 1 hour not more).If remember me function is enabled a user must be notified about with how many computers he/she has stored session and whether he/she wants to remove it or not. To get an idea implementation visit http://shetoldme.com/referral/7368c06b.A user can't be allowed to login from two computers at the same time.The domain and path scope of an application’s session cookies should be set as restrictively as possible.A site should be checked for XSS and CSRF attacks which can help an attacker attack session.To protect users in LAN environment the Network admin should implement SniffJoke. SniffJoke is Linux based anti-sniffing technology developed by Delirandom, for download and more information visit http://www.delirandom.net/ . You can implement any anti-sniffing technology but we are recommending SniffJoke because its free and open so you can not only download and use it but can also modify according to your needs. So here we end countermeasure against session management attacks. Thanks for reading, have a nice time and keep visiting.