Web Security Fundamentals

Web Security Foundation-based questions answered

1.SQL injection attack principle, how to defend?

The SQL injection attack refers to the introduction of a special input as a parameter to the Web application, which is mostly a combination of SQL syntax, the execution of SQL statements to perform the actions of the attacker, the main reason is that the program does not carefully filter the user input data, resulting in illegal data intrusion system.

Defensive measures:

1. Never trust the user's input.　　The user's input can be verified by regular expressions, or by limiting the length, by converting the single quotation mark and the double "-".　　2. Never use dynamically assembled SQL, either using parameterized SQL or directly using stored procedures for data query access.　　3. Never use a database connection with administrator rights, and use a separate limited database connection for each app.　　4. Do not store confidential information directly, encrypt or hash out passwords and sensitive information. 5. Application of exception information should be given as few hints as possible, preferably using a custom error message to wrap the original error message 6.sql injection detection method generally take the aid software or website platform to detect, the software generally uses SQL injection detection Tool Jsky, Website platform has billion think website security platform detection tools. Mdcsoft scan and so on. The use of mdcsoft-ips can effectively protect against SQL injection, XSS attacks and so on.

2.XSS attack principle, how to defend?

XSS is a computer security vulnerability that often appears in web applications, allowing malicious Web users to embed code into pages that are available to other users. For example, the code includes HTML code and client script.

Defensive measures:

1. Feature-based defenses

The keyword "javascript" is retrieved, once found that the submission contains "JavaScript", it is considered an XSS attack, but this method in addition to a large number of false negatives, there is a large number of false positives.

2. Code modification-based defenses

Step 1, to all user submissions for reliable input validation, including the URL, query keywords, HTTP headers, post data, and so on, only accept the specified length range, in the appropriate format, with the expected character of the content submitted, the other filter.　　Step 2, implement session marker (session tokens), CAPTCHA system or HTTP reference header check to prevent the function from being executed by third party websites. Step 3, confirm that the received content is properly normalized, contains only the smallest, secure tag (no JavaScript), remove any references to remote content (especially stylesheets and JavaScript), use HTTP only cookie.

3.CSRF attack principle, how to defend?

CSRF (Cross-site request forgery) cross-site requests forgery, also known as "one click Attack" or Session Riding, usually abbreviated as CSRF or XSRF, is a malicious use of the site. Although it sounds like cross-site scripting (XSS), it is very different from XSS, where XSS leverages trusted users within the site, while CSRF leverages trusted sites by disguising requests from trusted users.

Defensive measures:

For Web sites, switching a persisted authorization method (such as a cookie or HTTP authorization) to an instantaneous authorization method (providing a hidden field in each form) will help the site prevent these attacks.　　A similar approach is to include the secret information in the form, the user-specified code name as a validation outside of the cookie. Another option is to "double-commit" cookies. This method works only with Ajax requests, but it can be used as a global remediation method without changing a large number of form. If an authorized cookie is being read by the JavaScript code before the form post, then the restriction cross-domain rule will be applied.　　If the server needs to include a request for an authorization cookie in the POST request body or URL, the request must come from a trusted domain because the other domain cannot read the cookie from the trusting domain. Contrary to the usual trust idea, using post instead of the Get method does not provide effective protection. Because JavaScript can use forged post requests. Nonetheless, requests that cause "side effects" to security should always be sent using post.　　The Post method does not leave the data tail in the Web server and proxy server logs, but the Get method leaves the data tail. Although CSRF is a fundamental issue for Web applications, not a user's problem, users can protect their accounts on websites that lack secure design: By logging out of the site before browsing other sites or by clearing the browser's cookie after the end of the browser session. Experimental process Webgoat Environment

First put down the Webgoat jar, you can go to the official GitHub up and down, but I use the school network almost motionless, I was the last to go to the Yang Zhenghui provided in the network.

CD to the path of the jar package, enter

Java-jar webgoat-container-x.x. x-war-exec.jar

And wait until the prompt

Description WebGoat Service has been opened, open the browser to access Http://localhost:8080/WebGoat, the following page appears

Injection Flawslog Spoofing

General Goal (s):
* The grey area below represents what's going to being logged in the Web server ' s log file.
* Your goal is to make it like a username "admin" have succeeded into logging in.
* Elevate your attack by adding a script to the log file.

There is a login interface, the submission will appear in the log in the next record, the goal is to deceive the administrator "admin" user successfully logged in. The input text box does not have any content restrictions.

You can deceive the human eye by adding a newline character, enter the user name Smith%0d%0alogin succeeded for username:admin,%0d%0a is the/r/n line break, so that it is disguised as two logons in the log with one login. The results are as follows

String SQL Injection

General Goal (s):
　　The form below allows a user to view their credit card numbers. Try to inject a SQL string that results in all the credit card numbers being displayed. Try the user name of ' Smith '.

Do a test first and enter Smith to see what the results are.

　　

At this point, you can observe the SQL statements of the database

SELECT * from user_data WHERE last_name = ' Your name '

As long as the where is true to satisfy the topic requirements, so it can be constructed into a select * from user_data WHERE last_name = ' Your name ' or ' 1 ' = ' 1 ', the result is as follows:

Command Injection

General Goal (s):

The user should is able to execute any command on the hosting OS.

This problem needs to use Burpsuite Proxy server, modify the captured packets.

First configure the Burpsuite, if there is no burpsuite, you can directly apt-get install Burpsuite, and then terminal input Burpsuite can be opened.

Burpsuite has a lot of features, we only use its proxy, the first configuration of the new project is all by default, and then configure the local proxy server, listening on port 8000, the default is 8080, but conflicts with Webgoat. Burpsuite in the configuration of Firefox, preferences->advanced->network inside Configure Proxy Server

Note that no proxy for the contents of the deletion, there may be default localhost and 127.0.0.1 do not use the agent.

Start the problem after the configuration is complete. Still the first time normal input see return result

Notice that there is a sh-c here, which shows that the code behind it is executed,

You can see here that the contents of the check box should be put into this folder and cat view, naturally we think of cat and then continue to let him execute the command we want to execute, but because this is the check box, we have to burpsuite in the change. Open Burpsuite Intercept, then click View Submit again to view the packet as follows.

Obviously at this time the HelpFile parameter is the one we see above the stitching into the shell command parameters, so we try to change him, such as change to

Helpfile=basicauthentication.help "; Ifconfig" &submit=view

Click Forward to get the following results:

Description IFCONIFG successfully executed, successfully let the command execute.

Numeric SQL Injection

General Goal (s):

The form below allows employees to see all their personal data including their salaries. Your account is mike/test123. Your goal is-to-try to see other employees data as well.

Log in with each user name password mike/test123 , then you can get the corresponding data by check box, as shown in:

The topic has given the SQL statement, the next is very simple, the use of Burpsuite change station value, change it from 101 to 101 or 1=1, and then forward, get the following results, attack success.

Cross-site Scripting (XSS) Phishing with XSS

General Goal (s):
The user should is able to add a form asking for username and password. On submit the input should is sent to Http://localhost/WebGoat/catcher? Property=yes &user=catchedusername&password=catchedpasswordname

The goal is to search for a form that contains a username and password, and send the input to Http://localhost/WebGoat/catcher after submission? Property=yes &user=catchedusername&password=catchedpasswordname, you can first enter a simple form test, such as the form of the experiment 8 submitted to the results are as follows:

After that, we only need to change the JS function of onsubmit, and send the data to the corresponding path instead.

Stored XSS Attacks

General Goal (s):
The user should is able to add message content this cause another user to load an undesireable page or content.

Users can submit a title and a message to the server, and other users can click the title to view the message with the goal of embedding their own JS script or HTML page in the message via XSS.

If you submit any message, the results are as follows:

And then still try to take the form of experiment 8, and the result seems to be:

You can't do XSS attacks like title.

Reflected XSS Attacks

General Goal (s):
For this exercise, your mission are to come up with some input containing a script. You have a to-try-to-get this page to reflect. Input back to your browser, which'll execute the script and do somethin G bad.

Reflected XSS, the first rebound, in the form found in the possibility of returning to the browser parameters, it is only three digit access code server can be re-sent back to the browser, so put the JS script here, submit, found that alert appears, Indicates that the result is correct.

Cross Site Request forgery (CSRF)

Goal

Your goal is to send an e-mail to a newsgroup. The email contains an image whose URL was pointing to a malicious request. In this lesson the URL should the "attack" servlet with the lesson's "screen" and "menu" parameters and a extra Parameter "Transferfunds" has an arbitrary numeric value such as 5000. You can construct the link by finding the ' screen ' and ' menu ' values in the Parameters inset on the right. Recipients of CSRF emails that happen to being authenticated at that time would have their funds transferred. When this lesson's attack succeeds, a green checkmark appears beside the lesson name in the menu to the left.

The principle is to send a message to the victim, the email contains a link to the bank transfer, the link parameters are set up, but the successful execution of the transfer will require the victim's browser cookie can be successfully authenticated by the bank website, so that although the user just opened the link, The browser automatically accesses the image path, and the cookie is the victim's cookie, causing the transfer to be successful.

Enter the following code and click on the link

<src= "Http://localhost:8080/WebGoat/attack?" screen=280&menu=900&transferfunds=5000 "  width=" 1 "  height=" 1 " />

The results are as follows:

CSRF Prompt By-Pass

General Goal (s):
Similar to the CSRF Lesson, your goal are to send an email to a newsgroup that contains multiple malicious requests:the fi RST to transfer funds, and the second a request to confirm the prompt that the first request triggered. The URLs should point to the attack Servlets with this csrf-prompt-by-pass lesson's screen, menu parameters and with an ext RA parameter "Transferfunds" having a numeric value such as "Z" to initiate a transfer and a string value "CONFIRM" to Complete it. Can copy the lesson ' s parameters from the inset on the right to create the "the format" attack? Screen=xxx&menu=yyy&transferfunds=zzz ". Whoever receives this e-mail and happens to is authenticated at that time would has his funds transferred. When you think the attack are successful, refresh the page and you'll find the green check on the left hand side menu.

Type the following code

<formAccept-charset= ' UNKNOWN 'Method= ' POST 'Action= ' attack? Screen=xxx&menu=yyy 'enctype= ' application/x-www-form-urlencoded '>    <inputname= ' Transferfunds 'type= ' Submit 'value= ' CONFIRM '>    <inputname= ' Transferfunds 'type= ' Submit 'value= ' CANCEL '></form>

The results are as follows:

CSRF Token By-Pass

General Goal (s):
Similar to the CSRF Lesson, your goal are to send an email to a newsgroup that contains a malicious request to transfer fun Ds. To successfully complete your need to obtain a valid request token. The page that presents the transfer funds form contains a valid request token. The URL for the Transfer funds page is the ' attack ' servlet with the ' Screen ' and ' menu ' query parameters of this lesson a nd an extra parameter "Transferfunds=main". Load This page, read the token and append the token in a forged request to transferfunds. When you think the attack are successful, refresh the page and you'll find the green check on the left hand side menu.

Title Enter one, type the following code in the message

<Script>var Tokensuffix;        function readFrame1 () {var framedoc = document.getElementById ("Frame1"). Contentdocument;        var form = framedoc.getelementsbytagname ("form") [0]; Tokensuffix = '&csrftoken= ' + form.             Csrftoken.value;    LoadFrame2 ();        } function LoadFrame2 () {var testframe = document.getElementById ("frame2"); Testframe.src= "Attack? screen=273&menu=900&transferfunds=5000 "+ tokensuffix; }</Script> <iframesrc= "Attack?" Screen=273&menu=900&transferfunds=main "onload= "readFrame1 ();"ID= "Frame1"frameborder= "1"marginwidth= "0"marginheight= "0"width= "$"scrolling=yesHeight= "+"></iframe> <iframeID= "Frame2"frameborder= "1"marginwidth= "0"marginheight= "0"width= "$"scrolling=yesHeight= "+"></iframe>

Click Submit and click on the test link to get the following results:

Experimental experience

This experiment has a basic understanding and understanding of several common web attack SQL injection, XSS and csrf in practice. Although they may not be able to attack others, but know how others are attacking, at least know how to prevent, not to point a site was the money to be transferred away.

Web Security Fundamentals