CSRF Cross-Site Request Forgery Attack + Case Analysis

CSRF Cross-Site Request Forgery Attack + Case Analysis

I recently read "web Front-end hacker technology secrets", instead of trying to learn three abuse methods, just to prevent myself from being cheated...

Because the same-origin policy is adopted, it is still limited to implement cross-site attacks, but the freedom of network protocols still leaves many vulnerabilities.

XSS cross-site scripting attacks and CSRF cross-site request forgery attacks are newly exposed attacks.

XSS: Cross-site, as the name suggests, requires websites in different domains. For example, the official website is www.foo.com, and our malicious website is www.evil.com.

How can I get the cookie of a regular website and do what I want? Cross-site information is required.

Generally, XSS is divided into three types:

(1) reflected XSS

This is temporary. It is implemented using the get or post parameters. If the server has the echo function for our parameters, this can be implemented.

For example, the server will call eval (arg) for our requests)

So we only need to in http://www.foo.com? Add the js script we want to execute after alert ('icandoanything ') connection, and send the connection to the user and click it to execute the subsequent js script.

(2) Storage Type

For example, because website messages or blogs are stored permanently, all users who view this message or blog will be attacked if malicious code is embedded, fortunately, the well-known websites won't make code embedding so easily, especially scripts. I am also a little white. The specific method is Buji Island.

 

(3) DOM

By modifying the DOM node, for example, the imgsrc = http://www.evil.com/image can be added to the third-party resource quota...

 

Another attack is cross-site request forgery.

Generally, cross-site requests sent from URLs to html tags are not restricted by the same-origin policy. Therefore, third-party resources such as img, script, css style, and framework content should be loaded frequently.

This also leaves some backdoors for us ..

Here is a simple example .... If it is immoral, take the blog as an example. Not malicious, just to indicate that CSRF Cross-Site Request Forgery

(1) Get Request Forgery

Generally, a get request is used to delete a blog, followed by an article id. Therefore, if we can construct a connection with the deletion request and id, and the user has logged on to the blog in the browser, the cookie is used to disguise cross-site requests.

For example I have a draft blog and its deletion request is: http://write.blog.host.net/postlist/0/all/draft? T = del id = 11111111

Id refers to the Article id. You only need to click the connection ..... The article is deleted. Here we have successfully forged a request to delete others' blogs, but it is immoral ..

(2) Post Request Forgery

Generally, Post requests are used to submit articles, so we can help others write articles.

We often see that some of our social networks are inexplicably advertised, and we may be able to achieve this through ....

First, analyze the actual post request information.

Very simple. Use the developer debugging function F12 provided by the browser (in chrome)

Click network, clear the current content, and submit a blog normally. At this time, all request information will be captured. Pay attention to the post request, which is generally the request we want to use.

For example, we can see that the post request address already has the information required for Post. Well, we will use this to simulate post

 

Varf = document. createElement (formlink = the address drawn with a yellow highlighter in the diagram, right-click copy directly, because the previous header information is not displayed completely // define a function here, add data to form // the key value of FormData on the right is functionaddData (fm, key, value) {vare = document. createElement (inputfm. appendChild (e); e. type = texte. name = key; e. value = value; if (f) {body = document. body; document. body. appendChild (f); f. method = postaddData (f, titl, test4addData (f, typ, 1 addData (f, cont, nihaoaddData (f, desc, addData (f, tags, addData (f, flnm, addData (f, chnl, 0 addData (f, comm, 2 addData (f, level, 0 addData (f, tag2,) addData (f, artid, 0) addData (f, checkcode, undefined) addData (f, userinfo1, 121) addData (f, stat, draft)

In the end, how can someone else click on our connection?

Loading third-party resources is a loving and hateful guy.

Our webpage is embedded in imgsrc = Our forged request, which can be invisible to people.