Java Web security issues and solutions

1. Weak password vulnerability

Solution:

It is best to use a combination of numbers, letters, and special characters at least 6 digits for the password. The database does not store plaintext passwords, should be stored MD5 encrypted ciphertext, because the current ordinary MD5 encryption can be cracked, it is best to multi-MD5 encryption.

2. Do not use username and password login background can directly enter the background URL login system.

Solution:

Filters are configured to filter out connection requests for invalid users.

3. Exceptions thrown by JSP pages can expose program information. An experienced intruder can get a lot of information from the exception of the JSP program, such as part of the program's architecture, the physical path of the program, the information that the SQL injection explodes, and so on.

Solution:

Customize a exception to wrap the exception information without throwing it onto the page.

4. After the legitimate user "logout", in the case of not closing the browser, click the browser "Back" button, you can read the data from the local page cache, bypassing the server filter filtering.

Solution:

Configure filter to limit page caching for pages that hold sensitive information. Such as:

Httpresponse.setheader ("Cache-control", "No-cache"); Httpresponse.setheader ("Cache-control", "No-store"); Httpresponse.setdateheader ("Expires", 0); Httpresponse.setheader ("Pragma", "No-cache");

5.SQL injection vulnerability.

Solution:

Do not use "+" in the database access layer to splice SQL statements! Such as:

String sql= "SELECT * from USERS WHERE 1=1"; "if (Null! = User.getusername () &&!"). Equals (User.getusername ())) {SQL + = "and UNAME = '" +user.getusername () + "'";}

Instead, you should use PreparedStatement. Such as:

PreparedStatement pstmt = con.preparestatement ("select * from USERS WHERE uname=?"); Pstmt.setstring (1, "Neeke");

If the hibernate framework is used in your project, named parameter is recommended. Such as:

String queryString = "from Users where uname like:name";

After the colon is a named parameter, we can use the query interface to bind a parameter to the name parameter:

List result = Session.createquery (queryString)                  . setString ("name", User.getusername ())                  . List ();

6. File Upload vulnerability. The front desk only uses JS to filter the file suffix, which is only for ordinary users, and malicious attackers can modify the form to remove the JS check.

Solution:

Front-end JS filtering plus server-side program filtering. Specifically filter out which file types are subject to availability.

7. Executable script vulnerability. The data submitted by the user is not escaped, and some user-submitted information containing JavaScript scripts is directly exported to the page and executed by the browser.

Solution:

Use Org.apache.commons.lang.StringEscapeUtils to escape data submitted by the user. Such as:

@RequestMapping (params= "Method=addtopic", method=requestmethod.post) public Modelandview addtopic ( HttpServletRequest request, HttpServletResponse response, Bbstopic topic) {baseadmin user = (baseadmin) Request.getsession (). getattribute (Constant.session_user); Topic.setbaseadmin (USER); Topic.settopicdate (new Timestamp (System.currenttimemillis ())); Topic.settopiccontent (stringescapeutils.escapehtml ( Topic.gettopiccontent ())); Topic.settopictitle (stringescapeutils.escapehtml (Topic.gettopictitle ())); This.bbsTopicService.save (topic); return new Modelandview (New Redirectview ("bbs.do?method=topiclist&bfid=" + Topic.getbfid ()));}

8.Java Web container default configuration vulnerability. such as Tomcat background Management vulnerability, the default user name and password can be uploaded directly after the war file to get Webshell.

Solution:

It is best to remove the default path, password, and password if you need to use it to manage maintenance.

Java Web security issues and solutions