Questions d'entretien sur les nouvelles Java 2020 - Java Web (2)

1. Si le client désactive les cookies, la session peut-elle toujours être utilisée ?

Cookie et Session sont généralement considérés comme deux choses indépendantes. Session utilise une solution qui maintient l'état côté serveur, tandis que Cookie utilise une solution qui maintient l'état côté client. Mais pourquoi ne puis-je pas accéder à la session si je désactive les cookies ? Étant donné que la session utilise l'ID de session pour déterminer la session du serveur correspondant à la conversation en cours et que l'ID de session est transmis via Cookie, la désactivation de Cookie équivaut à perdre l'ID de session et vous n'obtiendrez pas la session.

Supposons que l'utilisateur utilise Session lorsque les cookies sont désactivés. Il existe plusieurs façons d'y parvenir :

• Définissez "session.use_trans_sid = 1 dans le php.ini. configuration file ", ou activez l'option "--enable-trans-sid" lors de la compilation pour permettre à PHP de transmettre automatiquement l'ID de session entre les pages.

• Transmettez manuellement la valeur via l'URL et transmettez l'ID de session via le formulaire masqué.

• Enregistrez l'ID de session dans un fichier, une base de données, etc., et appelez-le manuellement pendant le processus inter-pages.

2. Quelle est la différence entre le ressort mvc et les jambes de force ?

1. Différences dans les mécanismes d'interception

Struts2 est une interception au niveau de la classe. Chaque requête créera une action Lors de l'intégration avec Spring, la portée d'injection ActionBean de Struts2 est en mode prototype. . prototype, puis injectez les données de la requête dans la propriété via setter et getter. Dans Struts2, une action correspond à un contexte de requête et de réponse. Lors de la réception de paramètres, elle peut être reçue via des attributs. Cela montre que les paramètres d'attribut sont partagés par plusieurs méthodes. Une méthode d'Action dans Struts2 peut correspondre à une URL, mais ses attributs de classe sont partagés par toutes les méthodes. Cela signifie qu'il est impossible d'utiliser des annotations ou d'autres méthodes pour identifier sa méthode, et qu'elle ne peut être conçue que comme plusieurs instances.

SpringMVC est une interception au niveau de la méthode. Une méthode correspond à un contexte de requête, la méthode est donc fondamentalement indépendante et a un accès exclusif aux données de requête et de réponse. Chaque méthode correspond à une URL à la fois. Le paramètre passé est directement injecté dans la méthode, ce qui est unique à la méthode. Les résultats du traitement sont renvoyés au framework via ModeMap. Lors de l'intégration de Spring, le Controller Bean de SpringMVC est par défaut en mode Singleton, donc par défaut, un seul contrôleur sera créé pour toutes les requêtes. Il ne devrait y avoir aucune propriété partagée, il est donc thread-safe. Si vous souhaitez modifier la portée par défaut, vous devez le faire. ajoutez la modification de l'annotation @Scope.

Struts2 possède son propre mécanisme d'interception. SpringMVC utilise une méthode Aop indépendante, ce qui fait que la quantité de fichiers de configuration de Struts2 est plus grande que celle de SpringMVC.

(Tutoriels associés recommandés : programme d'entrée Java )

2. Différences dans les frameworks sous-jacents

Struts2 est implémenté à l'aide de Filter (StrutsPrepareAndExecuteFilter), SpringMVC ( DispatcherServlet ) est implémenté à l'aide de Servlet. Le filtre est initialisé après le démarrage du conteneur ; il plante après l'arrêt du service, plus tard que le Servlet. Le servlet est initialisé lors de son appel, avant l'appel de Filter, et est détruit après l'arrêt du service.

3. Performances

Struts2 est une interception au niveau de la classe. Chaque requête correspond à une nouvelle action de l'instance, qui doit charger toutes les injections de valeurs d'attribut. SpringMVC n'implémente aucune configuration. est basé sur la méthode d'interception qui consiste à charger un bean en mode singleton pour l'injection. Par conséquent, l’efficacité et les performances du développement SpringMVC sont supérieures à celles de Struts2.

4. Configuration

spring MVC et Spring sont transparents. La gestion et la sécurité de ce projet sont également supérieures à celles de Struts2.

3. Comment éviter l'injection SQL ?

• PreparedStatement (méthode simple et efficace)

• Utiliser des expressions régulières pour filtrer les paramètres entrants

• Filtrage de chaînes

• Appelez cette fonction dans JSP pour vérifier si elle contient des caractères illégaux

• Code de jugement de page JSP

4. Qu'est-ce qu'une attaque XSS et comment l'éviter ?

L'attaque XSS est également appelée CSS, le nom complet est Cross Site Script (attaque de script intersite). Le principe est que l'attaquant entre du code HTML malveillant dans un site Web présentant des vulnérabilités XSS. Lorsque l'utilisateur navigue sur le site Web, ce code HTML sera automatiquement exécuté pour atteindre l'objectif de l'attaque.

Les attaques XSS sont similaires aux attaques par injection SQL. Dans les attaques par injection SQL, les instructions SQL sont utilisées comme entrée utilisateur pour interroger/modifier/supprimer des données. Dans les attaques XSS, des scripts malveillants sont insérés pour cibler le contrôle du navigateur. obtenir des informations sur l'utilisateur. XSS est une vulnérabilité courante dans les programmes Web. XSS est une méthode d'attaque passive utilisée côté client.

L'idée générale de la prévention XSS est la suivante : filtrer l'entrée (et les paramètres d'URL) et encoder la sortie.

(Tutoriel vidéo recommandé : Tutoriel vidéo Java)

5. Qu'est-ce qu'une attaque CSRF et comment l'éviter ?

CSRF (Cross-site request falsification) est également appelé attaque en un clic ou session riding. Le nom chinois complet est cross-site request falsification. De manière générale, un attaquant falsifie une requête provenant du navigateur de l'utilisateur et l'envoie à un site Web que l'utilisateur s'est authentifié pour visiter, de sorte que le site Web cible reçoit et pense à tort qu'il s'agit de l'opération réelle de l'utilisateur et exécute la commande. Couramment utilisé pour voler des comptes, transférer de l'argent, envoyer de faux messages, etc. L'attaquant exploite la vulnérabilité de vérification des demandes du site Web pour mettre en œuvre une telle attaque. Le site Web peut confirmer que la demande provient du navigateur de l'utilisateur, mais ne peut pas vérifier si la demande provient de la véritable intention de l'utilisateur.

Comment éviter :

1. Vérifiez le champ HTTP Referer

Le champ Referer dans l'en-tête HTTP enregistre l'adresse source de la requête HTTP. Dans des circonstances normales, la demande d'accès à une page à sécurité restreinte provient du même site Web, et si un pirate informatique souhaite y mettre en œuvre une attaque CSRF, il ne peut généralement construire la demande que sur son propre site Web. Par conséquent, les attaques CSRF peuvent être défendues en vérifiant la valeur Referer.

2. Utilisez le code de vérification

Ajoutez le code de vérification aux pages d'opération clés Après avoir reçu la demande, l'arrière-plan peut juger le code de vérification pour empêcher CSRF. Mais cette méthode n’est pas très conviviale.

3. Ajoutez un jeton à l'adresse de la demande et vérifiez

La raison pour laquelle l'attaque CSRF réussit est que les pirates peuvent complètement falsifier la demande de l'utilisateur et que toutes les informations de vérification de l'utilisateur contenues dans la demande existent dans cookies, afin que les pirates puissent utiliser directement les propres cookies de l'utilisateur pour passer la vérification de sécurité sans connaître les informations de vérification.

Pour résister au CSRF, la clé est de mettre dans la requête des informations que les pirates ne peuvent pas falsifier, et ces informations n'existent pas dans le cookie. Vous pouvez ajouter un jeton généré aléatoirement en tant que paramètre à la requête HTTP et créer un intercepteur côté serveur pour vérifier le jeton. S'il n'y a pas de jeton dans la requête ou si le contenu du jeton est incorrect, on considère qu'il peut l'être. une attaque CSRF et la demande sera rejetée.

Cette méthode est plus sûre que la vérification du référent. Le jeton peut être généré une fois que l'utilisateur s'est connecté et placé dans la session. Ensuite, le jeton peut être retiré de la session à chaque demande et mis en correspondance avec le jeton présent. la requête. Comparez, mais la difficulté de cette méthode est de savoir comment ajouter le jeton à la requête sous forme de paramètres.

Pour les requêtes GET, le jeton sera ajouté à l'adresse de la requête, de sorte que l'URL devienne

http://url?csrftoken=tokenvalue

Pour les requêtes POST, ajoutez

<input type="hidden" name="csrftoken" value="tokenvalue"/>

De cette manière, le token est ajouté à la requête sous forme de paramètre.

4. Personnalisez les attributs dans l'en-tête HTTP et vérifiez

Cette méthode utilise également des jetons pour la vérification. La différence par rapport à la méthode précédente est que le jeton n'est pas utilisé ici à la place. en le plaçant dans la requête HTTP en tant que paramètre, placez-le dans un attribut personnalisé dans l'en-tête HTTP. Grâce à la classe XMLHttpRequest, vous pouvez ajouter l'attribut d'en-tête HTTP csrftoken à toutes les requêtes de ce type en même temps et y insérer la valeur du jeton.

Cela résout l'inconvénient de l'ajout d'un jeton à la requête dans la méthode précédente. Dans le même temps, l'adresse demandée via XMLHttpRequest ne sera pas enregistrée dans la barre d'adresse du navigateur et il n'y a pas lieu de s'inquiéter de la question. le jeton est divulgué sur d'autres sites Web via le référent.

Si vous souhaitez en savoir plus sur les questions d'entretien connexes, vous pouvez visiter la colonne

questions d'entretien Java.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!