Web security scanning issues (common) analysis and solutions

650) this.width=650; "Src=" https://s5.51cto.com/wyfs02/M01/9E/22/wKiom1mL8nfxX3nQAABLOpisy7g392.png-wh_500x0-wm_ 3-wmp_4-s_268086774.png "title=" qq picture 20170810133609.png "alt=" Wkiom1ml8nfxx3nqaablopisy7g392.png-wh_50 "/>

This is a website I scanned in the morning

A lot of places don't know how to do it online.

Serious questions have session fixtion,vulnerable JavaScript library.

1. What is session fixation attack
Session fixation someone translates into "session completion attack", in fact fixation is the certainty and certainty of meaning, in this case, the Web service's session ID is fixed, the attacker is injured to determine a session ID to achieve the purpose of the attack. There is a special entry in Wikipediahttp://en.wikipedia.org/wiki/Session_fixation, citing its attack scenario, the precautionary strategy references the original.
Attack scenario
Alice is the victim of the original, she used a bank website http://unsafe/the session fixation loophole, Mallory is an attacker, he wanted to steal Alice's bank deposit, Alice will click on Mallory to send her web connection (either because Alice knows Mallory or her own security awareness is not strong).
Attack Scenario 1: Simplest: The server receives any session ID
The process is as follows:
1.Mallory Discovery Http://unsafe/receives any session ID, and the session ID is carried to the server through the query parameters of the URL address, the server does not check
2.Mallory send Alice an e-mail that he may pretend to be a bank in the promotion of his new business, for example, "We have launched a new service, the first experience please click: http://unsafe/?" Sid= I_will_know_the_sid, I_will_know_the_sid is a session ID selected by Mallory.
3.Alice was attracted, clicked Http://unsafe/?SID= I_will_know_the_sid, as usual, entered his own account and password to log in to the bank's website.
4. Because the session ID of the server does not change, now Mallory Click Http://unsafe/?SID= I_will_know_the_sid, he has the identity of Alice. Can do whatever it pleases.
Attack Scenario 2: The session ID generated by the server does not change
The process is as follows:
1.Mallory accesses the http://unsafe/and obtains a session ID (SID), such as the form returned by the server: SET-COOKIE:SID=0D6441FEA4496C2
2.Mallory sent Alice a message: "We have launched a new service, the first experience please click: http://unsafe/?SID=0D6441FEA4496C2
3.Alice Click and log in, what happens behind is the same as scenario 1
Attack Scenario 3: Cross-site Cookie (cross-site cooking)
Exploit browser vulnerabilities, even though Http://good is secure, but because of the vulnerability of browser management cookies, the malicious website http://evil/be able to send Http://good cookies to the browser. The process is as follows:
1.Mallory send Alice a message "There's an interesting website: Http://evil is fun, try it."
2.Alice visited this link, which set a session ID value of I_WILL_KNOW_THE_SID's http://good/domain cookie to the browser.
3.Mallory also sent Alice a message: "We have launched a new service, the first experience please click: http://good/"
4. If Alice is logged in, Mallory can take advantage of this ID.

In Java EE, Scenario 1 should be impossible, because the session ID is generated by the server
For today's browsers, scenario 3 is not an estimate.
Only scenario 2 The most reliable, first own access to a website, get their session ID, and then put this sessionid stitching in the URL to send others to visit, as long as that person a login, we are equivalent to log on

2. What is the vulnerable JavaScript library

The Fragile javascrpts Library

I didn't get a detailed explanation on the Internet either.

In my understanding this method is to replace the use of JS Library, or modify the relevant JS

Medium problem has

1.HTML form is not CSRF protected

The form data uploaded to the background is not filtered or urlencode

2.DoS attack--http denial of Service Attack

3. User credential information sent in clear text credentials is sent in clear

The account and password are sent directly to the backstage: name=aaa&password=123456

Low problem

1. Click Hijack clickjacking:x-frame-options Header missing

2. Password guessing attack login page password-guessing attack

3.SESSION and cookies are not set HttpOnly identifier session cookie without HttpOnly flag set

Modify the default SessionID generation mode;

Session settings httponly,f12 See, HTTP tools can see;

Cookie settings, the content of the cookie is: username=xxx ... Not encrypted

4. Sensitive catalogue Possible sensitive directories

Take to the Tomcat deployment directory

This article from "Big Plum" blog, declined reprint!

Web security scanning issues (common) analysis and solutions