The previous few essays about servlets have sorted out the simple usage process of servlets. The next article will mainly focus on the mobile APP access interface, md5 encryption transmission---->SMS verification--->Mobile push---->Sharing--->Baidu Cloud Map----->Payment...Third-party business... Since I am a novice, I also learn and write while learning, and I hope to understand the shortcomings.
Today's article mainly involves the encryption of javaservlet transmission data, the combination of client request parameters, and will come with all the problems I encountered in the middle and solutions.
Since the mobile phone access interface is published, no matter what language the interface is written, we should take corresponding security measures. Otherwise, after people know your URL, intercept the client's request and then modify the submission parameters, which will cause great losses. The most commonly used servlet writing interface should also encrypt the transmitted data. If it is written with webservice .net wcf and other technologies, it will also involve certificate matching...
1. Ideas for encryption and implementation of requested data parameters.
Encryption Here I use md5 32-bit encryption. 32-bit is an irreversible encryption. In this way, even if it is intercepted by a hacker, there is no way to decrypt the MD5 value we encrypted into a string combined when we encrypt. Of course this is not absolute. It seems that some computer experts have deciphered the encryption method of MD5 in the past few years, but I think that the technology may not be published at will at will, and even if it is announced, it is not something that ordinary people can understand. Otherwise, if you just ask a programmer, are you still using MD5 encryption? The answer is definitely no more.
1. First of all, let me talk about the combination of my request parameters. Because this involves MD5 encryption, we must feedback the user two tokens after the user logs in to the account using the APP. The first token is the only value indicating the user's identity. This token needs to be added to the request interface parameter (whether this parameter participates in encryption, it is up to you to determine whether it participates in encryption. I participated here), because the servlet needs to query the user's encryption required to query the user's encryption. The second token is used to encrypt the value of md5. This token cannot be added to the request interface parameters, and we must save both tokens in the database, because after the user requests the interface, servlet needs to obtain the user token in the parameters and then query the token required for md5 encryption in the database. Then the servlet then adds the encrypted tokens from the query to the string passed by the user, and performs an md5 encryption again. After encryption, compare the encrypted value of md5 encrypted by the user. Whether it is the same as the encrypted value of servlet. If it is different, then there may be two reasons. The encryption string combination on the servlet side is incorrect, and the user has intercepted and modified in the middle of the transmission of data. I used both tokens to generate them using java uuid, and what should be generated for uuid is a unique value. The generation method is very simple. Below is the code
public static String getUUID() { return UUID.randomUUID().toString(); }Below is the java md5 32-bit encryption method
public static String md5Encrypt(String groupParamertStr) throws UnsupportedEncodingException { MessageDigest messageDigest = null; try { messageDigest = MessageDigest.getInstance("MD5"); messageDigest.reset(); messageDigest.update(groupParamertStr.getBytes("UTF-8")); } catch (NoSuchAlgorithmException e) { System.out.println("NoSuchAlgorithmException caught!"); System.exit(-1); } catch (UnsupportedEncodingException e) { e.printStackTrace(); } byte[] byteArray = messageDigest.digest(); StringBuffer md5StrBuff = new StringBuffer(); for (int i = 0; i < byteArray.length; i++) { if (Integer.toHexString(0xFF & byteArray[i]).length() == 1) md5StrBuff.append("0").append(Integer.toHexString(0xFF & byteArray[i])); else md5StrBuff.append(Integer.toHexString(0xFF & byteArray[i])); } return md5StrBuff.toString(); } The following is a comparison of the encryption results with the encryption results passed by the user request after obtaining the parameters on the servlet. If the same means that the request is fine, otherwise the request parameter value may have been modified
//The following three parameters are the user token. The second is the parameter required for encryption. After we query the encrypted token through the user token, we need to splice it into the json string required for servlet encryption. The third is the encryption result string sent from the client. Here, the method returns 0 to indicate that there is no problem with the user's encryption result, otherwise there is an error public static int postTokenVerify(String token, JSONObject requestJsonObject, String encryptStrValue) { int returnValue=0; String[] mysqlParameter=new String[]{token}; //The following is querying the user's encryption token through the user token ResultSet returnData=MySqlHepler.executeQuery("select * from infosheet where idToken=?", mysqlParameter); JSONObject returnObject=null; try { returnObject = ResultToJsonTool.resultSetToJsonObject(returnData); } catch (SQLException e1) { // TODO Auto-generated catch block e1.printStackTrace(); } catch (JSONException e1) { // TODO Auto-generated catch block e1.printStackTrace(); } String byEncryptStrValue=""; try { if (returnObject.getString("encryptToken").length()>2) {//Indicate that the user's idToken exists, // return returnValueString; //{"idToken":"123456","id":"34","pwd":"23","encryptToken":"2345678","account":"hang"} /*The following code is matching the JAVAMD5 encryption string, Because when the user is encrypted, an encrypted token is added to the encrypted string, but the encrypted token cannot be passed during request. Therefore, when we encrypted the servlet, we need to query the user's encrypted toke through the user's token. After the query is found, we need to splice it and request the parameter json, so that the encrypted string of the servlet is consistent with the string encrypted by the user. The following is the method to query the encrypted token and splice it into the request parameters after querying out the encrypted token. */ byEncryptStrValue=requestJsonObject.toString().substring(0, requestJsonObject.toString().length()-1); JSONObject encryptTokenJsonObject=new JSONObject(); encryptTokenJsonObject.put("encryptToken",returnObject.getString("encryptToken")); String value1=encryptTokenJsonObject.toString().substring(1, encryptTokenJsonObject.toString().length()); byEncryptStrValue=byEncryptStrValue+","+value1; // } else { returnValue=1;// idtoken error} } catch (JSONException e1) { // TODO Auto-generated catch block e1.printStackTrace(); } try { // The following method is to use the correct string to encrypt the method call on the servlet. After returning a result, compare the encryption result passed by the user String javaMd5Result=EncryptSafa.md5Encrypt(byEncryptStrValue); if (javaMd5Result.equals(encryptStrValue)) {//The encryption string is correct} else { returnValue= 2;//The encryption result is wrong} } catch (UnsupportedEncodingException e) { // TODO Auto-generated catch block e.printStackTrace(); } return returnValue; }The first one is the encapsulated method called by the servlet. Below are all the codes called by the servlet page.
1. The requested URL
Here I am passing a dictionary to convert the json format parameter, which is a key-value pair form, and only one parameter is used for requesting it. The idToken in the parameter is the user token, and the value I add is a random 123456 in the database.
If you don't use uuid, of course, it will definitely not be the case if you do it formally.
http://localhost:8080/JAVAServletTest/2.jsp?parameter={"parameter":"{/"idToken/":/"123456/",/"pwd/":/"Chinese characters/",/"account/":/"hang/"}","md5Str":"672f4a8c6fb92103c01d4275e46df790"}
The following is the code processed by the servlet page. The entire process is to verify whether the user request has been modified during the delivery.
//I encountered a problem here yesterday. When I requested the parameters with Chinese, the servlet was garbled after getting the servlet, and then I used the following method. String requestJsonStr=new String(request.getParameter("parameter").getBytes("ISO8859-1"),"UTF-8"); //Submit parameters JSONObject objectParameter=null; //idToken JSONObject requestParmeter=null; //idToken String idToken=""; //Client encryption string String md5Str=""; try { //Get the total JSON string. This is actually the parameter objectParameter that we only pass from the URL.ObjectParameter=new JSONObject(requestJsonStr); //Submit the parameter, a key value of json, and request the paramter inside the parameter. In fact, this parameter contains the required parameters in the business, such as requestParmeter=new JSONObject(objectParameter.getString("parameter")); //idToken This is the user token, which is the user's unique identifier. We need to query the corresponding encrypted token in the database through it to query the idToken=requestParmeter.getString("idToken"); //The client encryption string md5Str=objectParameter.getString("md5Str"); } catch (JSONException e1) { // TODO Auto-generated catch block e1.printStackTrace(); } //The string generated after MD5 encryption//The next step is to verify whether the token is correct int tokenVerifyResult=EncryptSafa.postTokenVerify(idToken, requestParmeter, md5Str); if (tokenVerifyResult==0) { out.println("token encryption method is correct"); } else { out.println("encrypted token or encryption method error"); return; }The above is all the content of this article. I hope it will be helpful to everyone's learning and I hope everyone will support Wulin.com more.