1. Description de la vulnérabilité
Le logiciel Apache Tomcat est une implémentation open source des spécifications Jakarta Servlet, Jakarta Server Pages, Jakarta Expression Language, Jakarta WebSocket, Jakarta Annotations et Jakarta Authentication. Apache Tomcat implémente la prise en charge de Servlet et JavaServer Page (JSP) et fournit des fonctions uniques en tant que serveur Web, telles que la plate-forme de gestion et de contrôle Tomcat, la gestion du domaine de sécurité et les vannes Tomcat. En tant que serveur d'applications Web gratuit et open source, le serveur Tomcat est un serveur d'applications léger. Il est largement utilisé dans les systèmes de petite et moyenne taille et les occasions où il n'y a pas beaucoup d'utilisateurs à accès simultané. C'est le premier choix pour développer et déboguer JSP programmes. Le 22 mars 2023, l'agence de sécurité a publié une vulnérabilité de sécurité dans Apache Tomcat. La vulnérabilité provient du fait que l'agent utilisateur peut transmettre des cookies de session via entraînant une fuite d'informations. Selon une analyse pertinente, c'est parce qu'il peut être redirigé vers une connexion http lors de la demande https , ce processus entraînera un risque de piratage de session, entraînant une transmission non sécurisée de cookies ou de sessions. Les attaquants peuvent exploiter cette vulnérabilité pour divulguer des cookies ou des sessions sans autorisation, entraînant éventuellement la fuite de informations sensibles du serveur.
Informations de base : Type de vulnérabilité Divulgation d'informations sensibles
Code CVE : CVE-2023-28708
Score cvss : 4
Niveau de menace : Risque moyen
Heure de publication : 2023-03-22 00:00:00
Portée de l'influence : La version en direct est tomcat 9.0.46
11.0.0-M1 ≤ Apache Tomcat ≤ 11.0.0-M2
10.1.0-M1 ≤ Apache Tomcat ≤ 10.1.5
9.0.0-M1 ≤ Apache Tomcat ≤ 9.0.71
8.5.0 ≤ Apache Tomcat ≤ 8.5.85
2. Gestion des vulnérabilités
1) Validation des versions
#Windows 执行：
catalina version
#linux
sh ./bin/version.sh
2) Suggestion de correctif officiel
Actuellement, la dernière version a été officiellement publiée et les utilisateurs concernés sont invités à mettre à jour et à mettre à niveau vers la dernière version à temps . Les liens vers chaque version sont les suivants :
Série Apache Tomcat 11 : https://tomcat.apache.org/download-11.cgi
Série Apache Tomcat 10 : https://tomcat.apache.org/download-10.cgi
Série Apache Tomcat 9 : https://tomcat .apache.org/download-90.cgi
Série Apache Tomcat 8 : https://tomcat.apache.org/download-80.cgi
Étant donné que tomcat 9.0.46 est utilisé sur site, il est mis à niveau vers la dernière version : 9.0.76. Compte tenu de l'environnement du fabricant, il est temporairement mis à niveau vers la version 9.0.75 ;
Vous pouvez également vous référer au commit de réparation officiel :
3) mise à niveau
wget https://dlcdn.apache.org/tomcat/tomcat-9/v9.0.76/bin/apache-tomcat-9.0.76.tar.gz
wget https://dlcdn.apache.org/tomcat/tomcat-9/v9.0.76/bin/apache-tomcat-9.0.75.tar.gz
tar -xzf apache-tomcat-9.0.75.tar.gz
#备份
cp -r /tomcat9/bin/ /tomcat9/bin_bak
cp -r /tomcat9/lib/ /tomcat9/lib_bak
#停止老版本tomcat
sh /tomcat9/bin/shutdown.sh
#替换
mv apache-tomcat-9.0.75 apache-tomcat-9
mv /tomcat9/bin /tomcat9/bin_old
mv /tomcat9/lib /tomcat9/lib_old
cp ./apache-tomcat-9/bin /tomcat9/
cp ./apache-tomcat-9/lib /tomcat9/
#开启热加载和热部署
vim ./tomcat9/conf/server.xml #Host标签中加上一个配置
<Context docBase="xxx" path="/xxx" reloadable="true"/> #reloadable="true"
……
<Context docBase="xxx" path="/xxx" autoDeploy="true"/> #autoDeploy="true"，开启热部署
#.启动新版本tomcat
sh /tomcat9/bin/startup.sh
#验证
sh /tomcat9/bin/version.sh
3. Annexe
1) Chargement à chaud vs déploiement à chaud
Chargement à chaud : la mise en œuvre du chargement à chaud démarre un thread d'arrière-plan dans le conteneur Web, détecte périodiquement les modifications apportées aux fichiers associés et recharge la classe en cas de modification. Ce processus n'effacera pas la session. Pendant le processus, le serveur surveillera les modifications des fichiers de classe , y compris web-inf/class, wen-inf/lib, web-inf/web.xml et d'autres fichiers. S'il y a une modification, elle sera chargée localement sans effacer la session ou libérer la mémoire. Il est beaucoup utilisé en développement, mais la situation de débordement de mémoire doit être prise en compte . Tomcat n'active pas le chargement à chaud par défaut.
Déploiement à chaud : le déploiement à chaud consiste à vérifier périodiquement le fil d'arrière-plan de l'application Web. Si des modifications sont trouvées, l'intégralité de l'application Web sera rechargée. Cette méthode effacera complètement la session. De cette manière, l'ensemble du projet équivaut à un redéploiement, y compris la recréation d'un fichier .war. La session sera effacée et la mémoire sera libérée. Lorsque Tomcat démarre, il décompresse le package war dans l'application Web dans son répertoire, puis l'encapsule dans un contexte pour un accès externe. Ensuite, le déploiement à chaud se produit lorsque le programme est en cours d'exécution, si nous modifions les choses dans le package War. Ensuite, Tomcat supprimera le dossier dans lequel le package War précédent a été décompressé et décompressera à nouveau le nouveau package War. Il est beaucoup utilisé lorsque le projet est empaqueté. Le déploiement à chaud est plus utilisé dans les environnements de production, ce qui convient aux applications qui sont fréquemment déployées et dont le démarrage est long, et aux applications qui ne peuvent pas être arrêtées. L'environnement de développement peut directement configurer la publication dans le serveur Eclipse.
Pour plus d'informations : https://blog.csdn.net/qq_24313635/article/details/114281148