Os ensaios anteriores sobre servlets resolveram o processo de uso simples de servlets. O próximo artigo se concentrará principalmente na interface de acesso a aplicativos móveis, na transmissão de criptografia MD5 ----> Verificação de SMS ---> Mobile Push ---> Compartilhamento ---> Baidu Cloud Map ----> Pagamento ... Empresas de terceiros ... Como sou um novato, também aprendo e escrevo enquanto aprendi e espero entender as contas.
O artigo de hoje envolve principalmente a criptografia dos dados de transmissão JavaServlet, a combinação de parâmetros de solicitação do cliente e virá com todos os problemas que encontrei no meio e nas soluções.
Como a interface de acesso ao celular é publicada, independentemente da linguagem a interface estar escrita, devemos tomar medidas de segurança correspondentes. Caso contrário, depois que as pessoas conhecem seu URL, intercepte a solicitação do cliente e modifique os parâmetros de envio, o que causará grandes perdas. A interface de escrita de servlet mais usada também deve criptografar os dados transmitidos. Se estiver escrito com o WebService .NET WCF e outras tecnologias, também envolverá a correspondência de certificados ...
1. Ideias para criptografia e implementação dos parâmetros de dados solicitados.
Criptografia aqui eu uso a criptografia MD5 de 32 bits. 32 bits é uma criptografia irreversível. Dessa forma, mesmo que seja interceptado por um hacker, não há como descriptografar o valor do MD5 que criptografamos em uma string combinada quando criptografamos. Claro que isso não é absoluto. Parece que alguns especialistas em computadores decifraram o método de criptografia do MD5 nos últimos anos, mas acho que a tecnologia pode não ser publicada à vontade à vontade e, mesmo que seja anunciada, não é algo que as pessoas comuns possam entender. Caso contrário, se você apenas perguntar a um programador, ainda está usando a criptografia MD5? A resposta definitivamente não existe mais.
1. Primeiro de tudo, deixe -me falar sobre a combinação dos meus parâmetros de solicitação. Como isso envolve a criptografia MD5, devemos fazer comentários ao usuário dois tokens depois que o usuário faz login na conta usando o aplicativo. O primeiro token é o único valor que indica a identidade do usuário. Esse token precisa ser adicionado ao parâmetro da interface de solicitação (se esse parâmetro participa da criptografia, cabe a você determinar se ele participa da criptografia. Participei aqui), porque o servlet precisa consultar a criptografia do usuário necessária para consultar a criptografia do usuário. O segundo token é usado para criptografar o valor do MD5. Esse token não pode ser adicionado aos parâmetros da interface de solicitação e devemos salvar os dois tokens no banco de dados, porque depois que o usuário solicita a interface, o servlet precisa obter o token do usuário nos parâmetros e, em seguida, consultar o token necessário para a criptografia MD5 no banco de dados. Em seguida, o servlet adiciona os tokens criptografados da consulta à sequência passada pelo usuário e executa uma criptografia MD5 novamente. Após a criptografia, compare o valor criptografado do MD5 criptografado pelo usuário. Se é o mesmo que o valor criptografado do servlet. Se for diferente, pode haver duas razões. A combinação de sequência de criptografia no lado do servlet está incorreta e o usuário interceptou e modificou no meio da transmissão de dados. Eu usei os dois tokens para gerá -los usando Java UUID, e o que deve ser gerado para UUID é um valor único. O método de geração é muito simples. Abaixo está o código
public static string getUuid () {return uuid.randomuuid (). tostring (); }Abaixo está o método de criptografia Java MD5 de 32 bits
public static string md5Encrypt (string groupparametstr) lança UnsupportEnCodingException {Messagedigest Messagedigest = null; tente {Messagedigest = Messagedigest.getInstance ("md5"); Messagedigest.Reset (); Messagedigest.Update (Groupparametstr.getBytes ("UTF-8")); } catch (nosuchalgorithMexception e) {System.out.println ("NosuchalgorithMexception capturado!"); System.Exit (-1); } Catch (UnsupportEdEncodingException e) {E.PrintStackTrace (); } byte [] bytearray = Messagedigest.digest (); StringBuffer md5strbuff = new StringBuffer (); para (int i = 0; i <bytearray.length; i ++) {if (intoger.toHexString (0xff & bytearray [i]). length () == 1) md5strbuff.append ("0"). Append (integer.ToHexstring (0xff & byTearRray [i]); caso contrário, md5strbuff.append (inteiro.tohexstring (0xff & bytearray [i])); } retornar md5strbuff.toString (); } A seguir, é apresentada uma comparação dos resultados da criptografia com os resultados da criptografia passados pela solicitação do usuário após obter os parâmetros no servlet. Se o mesmo significa que a solicitação estiver boa, caso contrário, o valor do parâmetro de solicitação pode ter sido modificado
// Os três parâmetros a seguir são o token do usuário. O segundo é o parâmetro necessário para a criptografia. Depois de consultar o token criptografado através do token do usuário, precisamos secá -lo na sequência JSON necessária para a criptografia do servlet. O terceiro é a sequência de resultados de criptografia enviada do cliente. Aqui, o método retorna 0 para indicar que não há nenhum problema com o resultado da criptografia do usuário, caso contrário, há um erro public static int pós -TOKENVERIFY (string token, jsonObject requestJsonObject, string EncryptStrValue) {int returnValue = 0; String [] mySqlParameter = new String [] {token}; // A seguir, está consultando o token de criptografia do usuário através do Token do usuário ResultSet ReturnData = mysqlhepler.executeQuery ("Selecione * da InfoSheet onde IdToken =?", MySqlParameter); JsonObject returnObject = null; tente {returnObject = resultadoTojSontool.ResultSettojsonObject (returnData); } catch (sqLexception e1) {// TODO BLOCO DE CAPAGEM AUTOGERATION E1.PRINTSTACKTRACE (); } catch (jsonexception e1) {// TODO BLOCO DE CATAGEM AUTOGERATION E1.printStackTrace (); } String byencryptStrValue = ""; tente {if (returnObject.getString ("EncryptToken"). Length ()> 2) {// indica que existe o IDToken do usuário, // 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 O token não pode ser aprovado durante a solicitação. Portanto, quando criptografamos o servlet, precisamos consultar o toke criptografado do usuário no token do usuário. Depois que a consulta é encontrada, precisamos unir e solicitar o parâmetro JSON, para que a sequência criptografada do servlet seja consistente com a string criptografada pelo usuário. A seguir, é apresentado o método para consultar o token criptografado e ceder nos parâmetros de solicitação depois de consultar o token criptografado. */ 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; // error idToken}} catch (jsonexception e1) {// TODO BLOCO DE CATAGEM AUTO-GOERATO E1.printStackTrace (); } tente {// O seguinte método é usar a sequência correta para criptografar a chamada do método no servlet. Depois de retornar um resultado, compare o resultado da criptografia aprovado pela sequência do usuário javamd5Result = EncryptSafa.md5Encrypt (byEnCryptStrValue); if (javamd5Result.equals (EncryptStrValue)) {// A sequência de criptografia está correta} else {returnValue = 2; // O resultado da criptografia está errado}} catch (não suportadaCodingException e) {// TODO GONERATOUNADO AUTO-GENERADO E.PrintStackTrace (); } retornar retornarValue; }O primeiro é o método encapsulado chamado pelo servlet. Abaixo estão todos os códigos chamados pela página do servlet.
1. O URL solicitado
Aqui estou passando por um dicionário para converter o parâmetro de formato JSON, que é um formulário de par de valores-chave, e apenas um parâmetro é usado para solicitá-lo. O IDToken no parâmetro é o token do usuário, e o valor que eu agregue é um 123456 aleatório no banco de dados.
Se você não usar o UUID, é claro, definitivamente não será o caso se o fizer formalmente.
http: // localhost: 8080/javaservlettest/2.jsp? parâmetro = {"parâmetro": "{/" idToken/":/" 123456/",/" pwd/":/" chinês caracteres/",/" conta/":/" hang/"}", "md5str": "672f4a8c6fb92103c01d4275e46df790"}
A seguir, é apresentado o código processado pela página do servlet. Todo o processo é verificar se a solicitação do usuário foi modificada durante a entrega.
// encontrei um problema aqui ontem. Quando solicitei os parâmetros com chinês, o servlet foi iluminado depois de obter o servlet e, em seguida, usei o seguinte método. String requestJSonstr = new String (request.getParameter ("parâmetro"). GetBytes ("ISO8859-1"), "UTF-8"); // Enviar parâmetros jsonObject ObjectParameter = null; // IDTOKN JSONOBJETEL SOITPERPARMETER = NULL; // IdToken String idToken = ""; // CRIPTIVO CLIENTE String String md5str = ""; tente {// obtenha a string JSON total. Na verdade, este é o parâmetro ObjectParameter que passamos apenas do url.ObjectParameter = novo JsonObject (requestJSonstr); // Envie o parâmetro, um valor de chave do JSON, e solicite o paramter dentro do parâmetro. De fato, esse parâmetro contém os parâmetros necessários no negócio, como requestParmeter = new jsonObject (objectParameter.getString ("parâmetro")); // IdToken Este é o token do usuário, que é o identificador exclusivo do usuário. Precisamos consultar o token criptografado correspondente no banco de dados através dele para consultar o idToken = requestParmeter.getString ("IdToken"); // a string de criptografia do cliente md5str = objectParameter.getString ("md5str"); } catch (jsonexception e1) {// TODO BLOCO DE CATAGEM AUTOGERATION E1.printStackTrace (); } // A sequência gerada após a criptografia md5 // a próxima etapa é verificar se o token está correto int tokenverifyResult = EncryptSafa.postTokenVifify (IdToken, requestParmeter, md5str); if (tokenVerifyResult == 0) {out.println ("O método de criptografia de token está correto"); } else {out.println ("Token criptografado ou erro do método de criptografia"); retornar; }O exposto acima é todo o conteúdo deste artigo. Espero que seja útil para o aprendizado de todos e espero que todos apoiem mais o wulin.com.