java servlet mobile phone app access interface of data encryption transmission verification

  • 2020-05-24 05:40:54
  • OfStack

The previous several essays on servlet sort out the simple use process of servlet, and the following articles will mainly focus on the mobile phone APP access interface, md5 encryption transmission -- > SMS verification -- > Mobile phone push -- > Share - > Baidu cloud map -- > Pay for... The business of the third party... Because I am a novice, I am also 1 side to learn 1 side to write, insufficient place hope understanding.

Today's article mainly deals with the encryption of the data transmitted by javaservlet, the combination of client request parameters, and all the problems I encountered along the way as well as the solutions.

Since the mobile access interface is published, we should take appropriate security measures no matter what language is used to write the interface. Otherwise, when people know your URL, they will intercept the client's request and then modify the submission parameters, thus losing a lot. The most common use of servlet write interface is to encrypt the transmitted data. If it is written by webservice.net, wcf or other such technologies, it will also involve the matching of certificates.

1. Encryption and implementation of request data parameters.

Encryption here I used md5 32-bit encryption, 32-bit is an irreversible encryption, so even if the hacker intercepted, there is no way to decrypt our encrypted MD5 value into the string we encrypted. Of course this is not absolute, as in previous years it has been a computer expert decoding MD5 encryption, but I think that technology may not be published at first, and then not even released 1 people can understand, or you ask a programmer MD5 encryption do you still use, it must answer is no.

1, first of all, I said I request parameters under the combination of ideas, because it involves MD5 encryption, so we must use APP in user login account after two token feedback to the user, the first token is only 1 value, said the identity of the users the token is need to add to the request of interface parameters (whether the parameters involved in encryption, is you don't, I here are involved in), because servlet need to query the user's encryption token needs through it, The value of the second token is used to encrypt md5 this token cannot be added to the requested interface parameters, and the two token we must be saved to the database, the request because the user interface, serlvet token users of the need to get parameters and then to the database query md5 encryption required token, then servlet queries to encryption token are then added to the user passed to string, again a md5 encryption, After encryption, compare the encrypted value of md5 passed by the user with the encrypted value of servlet. If not, there may be two reasons. The combination of the encrypted string of servlet is wrong, and the user has been intercepted and modified in the process of data transmission. I generated both token using java uuid, because uuid generates a unique 1 value. It's easy to generate. Here's the code


 public static String getUUID() 
 { 
 return UUID.randomUUID().toString(); 
  
 } 

Below is the 32-bit encryption method for java md5


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 that after obtaining the parameters of servlet and encrypting them, a comparison is made between the encryption result and the encryption result passed by the user request. If sample 1 indicates that the request is ok, otherwise the request parameter values may have been modified


// The following method 3 A parameter   The first 1 User is token  The first 2 These are the parameters required for encryption , We'll go through the user later token Query the   encryption token And then we need to splice it together servlet Encryption required json Go to the string, no 3 One is coming from the client   Encrypt the result string   Here the method returns 0 said   The result after the user encrypts does not have the problem, otherwise has the error 
 public static int postTokenVerify(String token, JSONObject requestJsonObject,
   String encryptStrValue) {
  int returnValue=0;
  String[] mysqlParameter=new String[]{token};
  // This is through the user token The query   User encryption 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) {// State the user's idToken There are ,
     // return returnValueString;
    
    //{"idToken":"123456","id":"34","pwd":"23","encryptToken":"2345678","account":"hang"}
    /* The following code is in match JAVAMD5 Encrypted string , 
      Because when the user encrypts, the encryption is added token To the encrypted string, but the encryption cannot be passed on request token , so we servlet Encryption is done by the user token To query the user's encryption toke,  Once the query is done, we need to splice the request parameters json In the back, like this servlet The encrypted string is the same as the user-encrypted string 1 The cause. The next step is to query out the encryption token After splicing to the method after the request parameter, 
     */
    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 wrong   By mistake 
     
    }
  } catch (JSONException e1) {
   // TODO Auto-generated catch block
   e1.printStackTrace();
  }
   
   
  try {
   // The following method is to concatenate the correct strings   in servlet On the encrypted method call, return 1 Compare the encryption results passed by the user 
   String javaMd5Result=EncryptSafa.md5Encrypt(byEncryptStrValue);
   
   if (javaMd5Result.equals(encryptStrValue)) {// The encrypted string is correct 
     
   }
   else
   {
    
    returnValue= 2;// There was an error in the encryption 
   }
   
  } catch (UnsupportedEncodingException e) {
   // TODO Auto-generated catch block
   e.printStackTrace();
  }
 
   return returnValue;
 }

Above are wrapped methods called by servlet, below are all the code called by servlet page

1. Requested URL

So what I'm passing here is 1 dictionary conversion json, 1 key-value pair, 1 request parameter. idToken in the parameter is user token, the value of which I randomly added 1 123456 in the database

uuid is not used, of course not officially.

http: / / localhost: 8080 / JAVAServletTest / 2. jsp & # 63; parameter = {" parameter ":" {\ "idToken \" : \ "123456 \" and \ "pwd \" : \ \ "characters", \ "account \" : \ "hang \"} ", "md5Str" : "672 f4a8c6fb92103c01d4275e46df790"}

The following is the code for the servlet page processing. The whole process is to verify whether the user request has been modified on the way.


 // I had a problem here yesterday, when I asked for Chinese in the parameter, servlet After the acquisition is garbled, after the use of the following way is good .
   String requestJsonStr=new String(request.getParameter("parameter").getBytes("ISO8859-1"),"UTF-8");
   
   // Submit parameters 
   JSONObject objectParameter=null;
  //idToken
   JSONObject requestParmeter=null;
  //idToken
   String idToken="";
  // The client encrypts the string 
   String md5Str="";
   try {
    // To obtain the total JSON The string, this is actually where we start from URL Just the one that's passed paramter1 A parameter 
    objectParameter=new JSONObject(requestJsonStr);
    // Submit parameters ,json the 1 a key Value inside the request parameter paramter, In fact, this parameter is put in the business required parameters, such as you log in   account   password   This type of 
    requestParmeter=new JSONObject(objectParameter.getString("parameter"));
     //idToken  This is the user token, He is the only one 1 Identification, we need to query the corresponding database through him   encryption token the 
     idToken=requestParmeter.getString("idToken"); 
     // The client encrypts the string  
     md5Str=objectParameter.getString("md5Str");
  } catch (JSONException e1) {
   // TODO Auto-generated catch block
   e1.printStackTrace();
  }
   
   
   
    //MD5 The encrypted string 
   
    // Under the 1 Step is to validate token Whether it is right 
   int tokenVerifyResult=EncryptSafa.postTokenVerify(idToken, requestParmeter, md5Str);
    if (tokenVerifyResult==0) {
     
     out.println("token Encryption method correct ");
     
      }
      
    else {
       out.println(" encryption token Or encryption error ");
       return;
       
     }

Related articles: