Dev Faq
10
votes

Authentification du nom d'utilisateur, mot de passe à l'aide de filtres en Java (en contactant avec la base de données)

Ce qui suit est la pièce de code Java à l'aide de filtres qui affiche la page d'erreur à chaque fois si le nom d'utilisateur et le mot de passe sont également corrects. Aidez-moi s'il vous plaît, je n'ai pas beaucoup de connaissances sur ce concept. 

String sql="select * from reg where username='"+user+"' and pass='"+pwd+"'";
rs=st.executeQuery(sql);
if(rs.next())
{
    chain.doFilter(request,response);
}
else
    sc.getRequestDispatcher("/error.html").forward(request,response);

2 commentaires

Que diriez-vous d'utiliser la sécurité de printemps? Petit et propre ...

@bastianneu: Et que diriez-vous d'utiliser la police d'assurance ING? Vous devriez penser avant de suggérer rien. Si quelqu'un n'obtient même pas un cadre, le printemps est loin, comment pouvez-vous simplement suggérer la sécurité du printemps. Je veux dire c'mon. Aucune infraction prévue.

4 Réponses :

3
votes

Utilisez une déclaration préparée, votre code est une invitation ouverte pour un Injection SQL . < Pré> xxx

Maintenant pour votre question, veuillez vérifier:

  • que les noms de table et de colonne sont la bonne (vous n'avez pas de "connexion" et une colonne "Nom d'utilisateur"?)
  • que les valeurs sont vraiment correctes (essayez la requête dans SQLDEvelopper par exemple)
  • qu'il fonctionne avec un mot de passe et un nom d'utilisateur ASCII-7 (il peut s'agir d'un problème de codage)
  • que la colonne de mot de passe contient le mot de passe réel et non un hachage de celui-ci
0 commentaires
1
votes

Tout d'abord, vous devez utiliser vraiment des requêtes paramétrées pour cela. Si l'utilisateur entre dans '"; Drop Table Reg; comme nom d'utilisateur, vous aurez de gros problèmes.

Aussi, êtes-vous sûr que le nom d'utilisateur et le mot de passe sont corrects? Que diriez-vous de la capitalisation?

0 commentaires
2
votes

Tant de choses qui ne vont pas avec ça ...: - /

  1. Le Big One - Injection SQL . N'écrivez pas une autre ligne de SQL dans votre code tant que vous le comprenez. Et ce n'est pas une exagération d'effet; Le code écrit sans compréhension de cela est susceptible de donner un accès arbitraire d'attaquant à votre base de données.
  2. Vous ne devriez pas être capable d'émettre une requête comme celle-ci car vous ne devez jamais stocker les mots de passe en clairexuel. Au lieu de cela, vous devez calculer et stocker une sorte de hachage de mot de passe (de préférence salé), puis de hachage le mot de passe soumis et comparez ceci. Voir, par exemple, Comment mieux magasiner Connexion et mot de passe et Salage de votre mot de passe ici. Ceci est surtout mauvais de votre vulnérabilité d'injection SQL.
  3. Sélectionnez * à partir de Reg est inutile que vous voulez juste savoir si une ligne existe. Si vous avez utilisé SELECT 1 au lieu de la place, la base de données n'aurait pas à inspecter le contenu de la ligne et pourrait servir les résultats de la requête uniquement à l'index. Si vous vous attendez à ce qu'il y ait beaucoup de lignes, Sélectionnez 1 où il existe ... serait plus rapide car cela permettrait à la DB de courte circulaire la requête après avoir trouvé au moins une ligne.
  4. Vous ne fermez pas la déclaration et le résultat défini dans enfin blocs. Cela signifie qu'ils ne sont pas garantis toujours (par exemple, s'il y a un SQLException lancé) menant aux fuites de ressources et de connexion.
0 commentaires
32
votes

chaîne SQL = "Sélectionnez * à partir de Reg où USERNAME = '" + utilisateur + "' et passe = '" + pwd + "'"; P>

C'est une très mauvaise pratique. Cette approche exige que le nom d'utilisateur et le mot de passe soient passés autour de la vanille ordinaire via des demandes. De plus, vous y êtes un trou d'attaque d'injection SQL. P>

Utilisez des sessions, dans JSP / servlet, vous avez le httpsession code> pour. Il n'y a vraiment pas non plus besoin de toucher la DB à nouveau et à nouveau sur chaque requête en utilisant un fichier code>. C'est inutilement coûteux. Il suffit de mettre utilisateur code> en session à l'aide d'un servlet code> et d'utiliser le filtre code> pour vérifier sa présence sur chaque demande. P>

Commencez par A /login.jsp code>: p> xxx pré>

puis, créez un logisservlet code> qui est mappé sur Modèle d'URL code> de / login code> et a le dopost () code> implémenté comme suit: p> xxx pré>

alors, créez un loginfilter code> qui est mappé sur URL-motif code> de / sécurisé / * code> (vous pouvez choisir votre choix, par exemple / protégé / * code>, / restreint / * code>, / users / * code>, etc., mais cela doit au moins couvrir toutes les pages sécurisées, vous devez également mettre les JSP dans le Dossier approprié dans WebContent) et possède le DOFILTER () CODE> implémenté comme suit: P> 

HttpServletRequest request = (HttpServletRequest) req;
HttpServletResponse response = (HttpServletResponse) res;
HttpSession session = request.getSession(false);
String loginURI = request.getContextPath() + "/login.jsp";

boolean loggedIn = session != null && session.getAttribute("user") != null;
boolean loginRequest = request.getRequestURI().equals(loginURI);

if (loggedIn || loginRequest) {
    chain.doFilter(request, response); // User is logged in, just continue request.
} else {
    response.sendRedirect(loginURI); // Not logged in, show login page.
}

0 commentaires

Articles qui pourrait vous intéresser :

Gspread - question d'erreur d'authentification - pas de dossier AppData
Utilisez l'attribut [Authorize] sur l'interface utilisateur Swagger avec ASP.NET Core Swashbuckle
Formulaire de connexion Symfony 4: authentification réussie, mais authentification immédiatement perdue après la redirection
Comprendre la sécurisation des jetons d'accès et des jetons d'actualisation