Web Test Security FAQ

Web Test Security FAQs

First, login account Text transmission

1, problem one: login password or change password plaintext transmission

Phenomenon: At present, the internal Java system of logistics is basically the plaintext transmission of user name and password

Use Firefox's own tools-developer-web, or HttpWatch tool to easily get information

When the tool is opened, the system is logged in and the software can get information automatically.

Suggestions:

Login using encrypted transmission, the general login is HTTPS encryption protocol

2, problem two: in the background log in clear print out the login account and password

Phenomenon:

Recommendation: More sensitive information in the log, such as passwords are used * Conversion display

Second, SQL injected

1, problem one: Some query input has the SQL injection risk

The so-called SQL injection attack is an attacker inserting a SQL command into a Web form's input domain or a page request query string, tricking the server into executing a malicious SQL command. In some forms, user-entered content is used directly to construct (or influence) dynamic SQL commands, or as input parameters to stored procedures, which are particularly susceptible to SQL injection attacks.

Phenomenon One:

SQL for the original login page:

SELECT COUNT (*) from Login WHERE username= ' admin ' and password= ' 123456 '

Login now Enter: ' Admin '--

SELECT COUNT (*) from Login WHERE username= ' admin '--password= ' 123 '

Because the "--" comment is entered in the username value, the subsequent statement is omitted and the login succeeds. (Often the method: preceded by '; ' (semicolon, used to end the previous statement), followed by '--' (for the statement behind the comment))

Phenomenon Two: Enter in the query statement: ' or ' 1=1 see if all the records are queried

Recommendation: Development do not directly write static SQL statements to query, need to use dynamic splicing SQL, for Web testing needs to the query site SQL injection test.

Note: The parameterized Query principle: In the case of parameterized queries, the database server does not treat the contents of the parameters as part of the SQL instruction, but only applies the parameters after the database completes the compilation of the SQL instructions, so even if the parameter contains a damaged instruction, it will not be run by the database.

Third, XSS Cross-site attacks

1, problem one: part of the system exists to submit the form when the input HTML code and JS code can be executed on the server

Cross-site scripting attacks (Scripting) Malicious attackers insert malicious script code into a Web page, and when a user browses to the page, script code embedded within the Web is executed to achieve the special purpose of a malicious attacker, such as:

<input>

<script>alert (' XSS ') </script>

Symptom: Enter <input> or <script>alert (' XSS ') in the text box </script>

After commit <input> and <script>alert (' XSS ') </script> as code executes the input box appears instead of being stored as a string

Suggestions:

Principle: Do not trust the data entered by the customer
Note: The attack code is not necessarily in <script></script>, there are other ways

1) Only allow users to enter the data we expect. For example: In a TextBox of age, only users are allowed to enter numbers. and the characters outside the numbers are filtered out.

2) HTML Encode processing of data

3) filter or remove or escape special HTML tags, for example: <script>, <iframe>, &lt; for <, &gt; For &quot;

Four, Cross-site forgery

1, problem one: constructs a POST request to make a request can be committed to the database

is an attack method that compelling users to perform unintended actions on the currently logged-on Web application, and is also available from third-party Web sites

Phenomenon: The following steps the user obtains to the request address, may construct the request message request parameter and the value by oneself, through the browser execution can also submit to the database that means there is a cross-site forgery

Suggestions:

Token verification

Attaching a portion of the information to each HTTP request is a good way to defend against a csrf attack, as it is possible to determine whether the request has been authorized. This "authentication token" should not be easily guessed by the user who is not logged in. If the request does not have this authentication token or token does not match, the server should reject the request.

Five, at present the general phenomenon Java layer not checked or not fully validated

In general, JS Checksum is a kind of auxiliary, the actual check should be placed on the server, if not do Java verification may exist

1) Use proxy tools such as Websarab to bypass page checking and directly tamper with data to insert data into the database;

2) The validation of the HTML layer does not prevent the user from falsifying the request, such as the token check above is one example;

3) Press Ctrl+f5 to force refresh commit, duplicate commit occurs

4) JS need browser download, if the browser download JS failure, the button is not grayed out users can repeatedly click, can appear repeated submissions, it also depends on the server side of the repeated submission to ensure

Six, borrowing Websarab tool to bypass the client's checksum to verify that the service checksum is

Seven, borrowing AppScan tool to automatically scan for security issues

Web Test Security FAQ