Session attack

1、 Certification and authorization

         A lot of times , People will put “ authentication ” and “ to grant authorization ” The two concepts are confused , actually “ authentication ” and “ to grant authorization ” Two things , The certified English is Authentication, Authorization is Authorization. It's actually very simple to distinguish these two concepts , Just remember ： The purpose of authentication is to recognize who the user is , The purpose of authorization is to decide what users can do .

         Vividly speaking , Suppose the system is a room , The person with the key can open the door and enter the house , Then the house is through “ Matching of lock and key ” To be certified , The process of authentication is the process of unlocking . The key is in the authentication process , go by the name of “ voucher ”（Credential）, The process of opening the door , In the Internet, the corresponding is login （Login）. But after opening the door , What can be done , What can't be done , Namely “ to grant authorization ” The jurisdiction of .

         If the owner of the house comes in , Then he can sit on the sofa and watch TV , You can also go into the bedroom to sleep , He can do whatever he wants , Because he has a room “ Highest authority ”. But if a guest comes in , Then you may only be allowed to sit on the sofa and watch TV , They are not allowed to enter the bedroom .

        “ Can I enter the bedroom ” The premise for this permission to be granted , Whether the person who needs to be identified is the host or the guest , So how to authorize depends on authentication . Now comes the question , The person who holds the key , Is it really the master ？ If the owner loses the key , Or someone has an identical key , That can also open the door , Enter the house . These abnormal conditions , It's because there's a problem with certification , The security of the system is directly threatened . The key is just a fragile credential , Others such as fingerprints 、 iris 、 Face 、 Biometrics such as voice can also be used as evidence to identify a person . Authentication is actually a process of verifying credentials .

         If only one certificate is used for authentication , It is called a “ Single factor certification ”; If two or more credentials are used for authentication , It is called a “ Two factors （Two Factors） authentication ” or “ Multifactor certification ”. Generally speaking , The intensity of multi factor certification is higher than that of single factor certification , But in terms of user experience , Multifactor authentication will bring some inconveniences more or less .

2、Session And certification

         Password, certificate and other authentication means , Generally, it is only used to log in （Login） The process of . When the login is complete , Users visit the pages of the website , It is impossible to use password authentication every time the browser requests a page . therefore , When the authentication is successful , You need to replace a credential that is transparent to the user . This voucher , Namely SessionID.

         When the user login is complete , A new session will be created on the server side （Session）, The user's status and related information are saved in the session . The server side maintains all online users Session, Authentication at this point , Just know which user is browsing the current page . To tell the server which one to use Session, The browser needs to put the current user's SessionID Inform server . The most common way is to put SessionID Encrypted and saved in Cookie in , because Cookie Will follow HTTP Request hair delivery , And protected by browser homology policy .

        Cookie Stored in the SessionlD,SessionID Once stolen in the life cycle , It's equivalent to account theft . At the same time as SessionID It is the authentication certificate held by the user after logging in , Therefore, hackers no longer need to attack the login process （ Like passwords ）, We need to be aware of this when designing the safety plan .

3、 conversation （Session） hijacked

         Session hijacking （Session hijacking） It's a way of stealing users SessionID after , Use this SessionID The attack method of logging into the target account , At this point, the attacker actually used the valid Session. If SessionID Is stored in the Cookie Medium , This attack can be called Cookie hijacked .

Attack steps ：

1. The target user needs to log in to the site first ;
2. After successful login , The user will get a session ID provided by the site SessionID;
3. An attacker captures by some means Session ID;
4. The attacker captured by Session ID Visit the site to get the legal session of the target user .

The attacker gets SessionID There are many ways ：

1. Brute force ： Try a variety of Session ID, Until it's cracked ;
2. forecast ： If Session ID Generate... In a non random manner , Then it is possible to calculate ;
3. steal ： Use network sniffing 、 Local Trojan theft 、XSS Attack and other methods to obtain . 

Defense methods ：

1、Cookie HttpOnly. By setting Cookie Of HttpOnly by true, It can prevent client script from accessing this Cookie, So as to effectively prevent XSS attack .

response.setHeader("Set-Cookie","user="+request.getParameter("cookie")+";HttpOnly");

SessionCookieConfig Interface , For operating sessions Cookie, stay ServletContextListener You can set it in the listener initialization method

@WebListener
public class SessionCookieInitialization implements ServletContextListener {
    private static final Log log = LogFactory.getLog(SessionCookieInitialization.class);
    public void contextInitialized(ServletContextEvent sce) {
        ServletContext servletContext = sce.getServletContext();
        SessionCookieConfig sessionCookie = servletContext.getSessionCookieConfig();
        // Set up HttpOnly
        sessionCookie.setHttpOnly(true);
    }
    public void contextDestroyed(ServletContextEvent sce) {
    }
}

2、Cookie Secure, It's settings COOKIE when , A property that can be set , After setting this property , Only in https During the interview , The browser will send this COOKIE. By default, browsers only need to use http Request a site , Will send clear text cookie, If there is monitoring in the network , May be intercepted . If web The whole site of application website is https Of , You can set cookie add Secure attribute , In this way, the browser will only https During the interview , send out cookie. Attackers even eavesdrop on the network , Also cannot get user plaintext cookie

response.setHeader("Set-Cookie"," user="+request.getParameter("cookie")+";HttpOnly;Secure");

perhaps

@WebListener
public class SessionCookieInitialization implements ServletContextListener {
    private static final Log log = LogFactory.getLog(SessionCookieInitialization.class);

    public void contextInitialized(ServletContextEvent sce) {
        ServletContext servletContext = sce.getServletContext();
        SessionCookieConfig sessionCookie = servletContext.getSessionCookieConfig();
        //  Set up HttpOnly
        sessionCookie.setHttpOnly(true);
        sessionCookie.setSecure(true);
    }

    public void contextDestroyed(ServletContextEvent sce) {
    }
}

4、 The conversation is fixed （Session fixation）

         The conversation is fixed （Session fixation） It is a way to trick the victim into using the session ID specified by the attacker （SessionID） The means of attack . This is the easiest way for an attacker to obtain a legitimate session id . Allow legitimate users to use the pre-set sessionID Log in , From then on Web Do not generate new sessionID, This leads to the... Set by the hacker sessionId Become a legal bridge .

         Session fixation can also be seen as a type of session hijacking , The reason is that the main purpose of session fixation attack is also to obtain the legal session of the target user , However, session fixation can also be used to force the victim to use a valid session set by the attacker , In order to obtain the user's sensitive information .

         What is? Session Fixation Well ？ Take an example of image , hypothesis A There is a car ,A Sold the car to B, however A Didn't give all the car keys to B, I also hid a handful myself . At this time, if B If you didn't change the lock of the car ,A You can still use the hidden key to use the car . This is not changed “ lock ” Security problems caused by , Namely Session Fixation problem .

Attack steps ：

1. The attacker resets the target user's password by some means SessionID, Then monitor the user's session status ;
2. The target user carries the... Set by the attacker Session ID Log in to the site ;
3. Through Session ID Get a legal session

How can an attacker make the target user use this SessionID Well ？ If SessionID Save in Cookie in , It is difficult to do this . But if SessionID Save in URL in , Then the attacker only needs to induce the target user to open this URL that will do . 

Defense methods ：【 A combination of several methods 】

1、 Reset whenever the user logs in sessionID

//  Session failure 
session.invalidate();
//  Session reconstruction 
session=request.getSession(true);

2、sessionID When idle for too long , To reset sessionID

3、 Disable client access Cookie, Set up HttpOnly

5、Session Keep attacking

         Generally speaking ,Session There is a life cycle , When the user is inactive for a long time , Or after the user clicks exit , The server will be destroyed Session.Session If it fails all the time , What's the problem ？ The previous chapter mentioned session Hijack attacks , It was the attacker who stole the user's SessionID, So that you can log in to the user's account .

         But if the attacker can always hold a valid Session（ For example, refresh the page at intervals ’ To tell the server that this user is still active ）, And the server for active Session If you don't destroy it all the time , An attacker can effectively Session— Directly use the user's account , Become a permanent ‘ back door .

however Cookie There is an expiration time ,Session It may also expire , Attackers can hold this permanently Session Do you ？

         General applications will give session Set an expiration time , When the expiration time is reached ,Session Will be destroyed . But there are some systems , For the sake of user experience , As long as this user still “ Alive ”, Will not let this user Session invalid . Thus, an attacker can send access requests constantly , Give Way Session always “ live ” down .

keep session Live for a long time ：

<script>
    // To maintain session Of url
    var url = "http://bbs.yuanjing.com/wap/index.php?/sid=LOXSAJH4M";
    // Timing task 
    window.setInterval("keeyId()",6000);
    function keepsid(){
        document.getElementById("iframe1").src=url+"&time"+Math.random();
    }
</script>
<iframe id="iframe1" src=""/></iframe>

Cookie Never expire ：

anehta.dom.persistCookie = function (cookieName){
        if(anehta.dom.checkCookie(cookieName)==false){
           return false;
        }
        try{
           document.cookie =  cookieName + "=" + anehta.dom.getCookie(cookieName)+";" + "expires=Thu, 01-Jan-2038 00:00:01 GMT;";
        } catch( e){
            return false;
        }
           return true;
    }

The attacker can even be Session Cookie Add one more Expire Time , It makes the original browser invalid when it is closed Cookie Persist locally , Become a third party Cookie（third-partycookie）.

Protection plan ：
         The common practice is after a certain time , Force to destroy Session. This time can be calculated from the time the user logs in , Set a threshold , such as 3 Days later, it will be forced Session Be overdue .

         But forced destruction Session It may affect some normal users , Another option is when the user's client changes , Ask the user to log back in . For example, the user's IP、UserAgent When the information changes , You can forcibly destroy the current Session, And ask the user to log in again .

         Last , It also needs to be considered that the same user can have several valid Session. If each user is allowed to have only one Session, Then the attacker wants to keep a Session It's also unlikely . When the user logs in again , What the attacker keeps Session Will be “ Kicked out ”.