Analysis of JSP Security Programming Example (Intermediate) 2

js| Security | programming
Four, always remember that SQL injection

General programming books teach beginners not to be aware of the habit of developing safe programming when they get started. The famous "JSP programming thought and practice" is this kind of demonstration to the beginner to write with the database login system (database for MySQL):

Statement stmt = Conn.createstatement ();
String checkUser = "SELECT * FROM login where username = '
"+ UserName +" ' and UserPassword = ' "+ UserPassword +" ' ";
ResultSet rs = stmt.executequery (CheckUser);
if (Rs.next ())
Response.sendredirect ("successlogin.jsp");
Else
Response.sendredirect ("failurelogin.jsp");



This makes the people who do the book long-term use such a congenital "hole" login code. If there is a user named "Jack" in the database, there are at least several ways to log in without knowing the password:
User name: Jack
Password: ' or ' a ' = ' a '
User name: Jack
Password: ' or 1=1/*
User name: Jack ' or 1=1/*
Password: (any)

Lybbs (Lingyun forum) ver 2.9.Server in the Loginout.java is the way to check the data submitted by the login:

if (S.equals ("") ││s1.equals (""))
throw new Userexception ("User name or password cannot be empty. ");
if (S.indexof ("")!= -1││s.indexof ("\")!= -1││s.indexof (",")!= -1││s.indexof ("\")!=-1)
throw new Userexception ("User name cannot include ' \" \ \ \ \ \ \ n) illegal characters. ");
if (S1.indexof ("")!= -1││s1.indexof ("\")!= -1││s1.indexof ("*")!= -1││s1.indexof ("\")!=-1)
throw new Userexception ("password cannot include" \ "\") illegal characters. ");
if (S.startswith ("") ││s1.startswith (""))
throw new Userexception ("Cannot use a space in a username or password.") ");



But I don't know why he just filtered the asterisk for the password and not the username. In addition, the forward slash appears to be listed in the blacklist. I still think that using regular expressions only allows you to enter characters within a specified range.

Here's a reminder: Do not assume that you can effectively withstand all attacks by virtue of the inherent "security" of some database systems. Pinkeyes's PHP Injection instance gives a lesson to those who rely on the "MAGIC_QUOTES_GPC = on" In the PHP configuration file.

V. Pitfalls of String objects

The Java platform does make secure programming more convenient. There is no pointer in Java, which means that the Java program no longer addresses any memory location in the address space as C does. Security issues are checked when a JSP file is compiled into a. class file, such as when an attempt to access an array element that exceeds the size of an array is denied, which largely avoids a buffer overflow attack. However, a string object can pose some security risks to us. If the password is stored in a Java String object, the password stays in memory until it is garbage collected or the process terminates. Even with garbage collection, it still exists in the free memory heap until the memory space is reused. The longer the password String resides in memory, the greater the risk of being tapped. Worse, if the actual memory is reduced, the operating system dispatches this password String to swap space on the disk, and is therefore vulnerable to disk block eavesdropping attacks. To minimize (but not eliminate) the possibility of this leak, you should store the password in a char array and place 0 on it after use (a String is immutable and cannot be placed 0).

Vi. A preliminary study of thread safety

"Java can do, JSP can do." Unlike scripting languages such as ASP and PHP, JSP is implemented by default in multi-threaded mode. Multi-threaded implementation can greatly reduce the resource requirements of the system, improve the system's concurrent volume and response time. Threads are separate, concurrent execution paths in a program, each thread has its own stack, its own program counter, and its own local variables. Although most operations in a multithreaded application can be done in parallel, there are certain actions, such as updating global flags or processing shared files, that cannot be done in parallel. If the thread is not synchronized, in large concurrent volume access, do not need the malicious user's "enthusiastic participation", the problem will arise. The simplest solution is to add a directive to the relevant JSP file to perform it in a single-threaded manner, at which point all client requests are executed serially. This can severely degrade the system's performance. We can still allow JSP files to be executed in a multi-threaded manner, by locking the function to synchronize the thread. A function, plus the Synchronized keyword, gets a lock. Look at the following example:

public class myclass{
int A;
Public Init () {//This method can be invoked concurrently by multiple threads
A = 0;
}
Public synchronized void Set () {//Two threads cannot call this method at the same time
if (a>5) {
A= a-5;
}
}
}



However, this will still have a certain impact on the performance of the system. A better solution is to use local variables instead of instance variables. Because instance variables are allocated in the heap, are shared by all threads belonging to the instance, not thread-safe, and local variables are allocated on the stack, because each thread has its own stack space, so the thread is safe. such as Lingyun forum to add friends code:

public void addfriend (int i, string s, string s1)
Throws Dbconnectexception
{
Try
{
If ...
Else
{
Dbconnect dbconnect = new Dbconnect ("INSERT INTO friend (Authorid,friendname) VALUES (?,?)");
Dbconnect.setint (1, i);
Dbconnect.setstring (2, s);
Dbconnect.executeupdate ();
Dbconnect.close ();
Dbconnect = null;
}
}
catch (Exception Exception)
{
throw new Dbconnectexception (Exception.getmessage ());
}
}



Here is the call:

Friendname=parameterutils.getstring (Request, "Friendname");
if (Action.equals ("AddUser")) {
Forumfriend.addfriend (Integer.parseint (Cookieid), friendname,cookiename);
Errorinfo=forumfriend.geterrorinfo ();
}



If you are using an instance variable, then the instance variable belongs to all thread shares of the instance, and it is possible that the user a passed a parameter to his thread to sleep, while the parameter is inadvertently modified by User B, causing the friend mismatch phenomenon.