<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Servlet on Java &amp; Moi</title><link>https://javaetmoi.com/tags/servlet/</link><description>Recent content in Servlet on Java &amp; Moi</description><generator>Hugo</generator><language>fr</language><lastBuildDate>Thu, 23 May 2013 18:45:16 +0000</lastBuildDate><atom:link href="https://javaetmoi.com/tags/servlet/feed.xml" rel="self" type="application/rss+xml"/><item><title>Mod_headers à la rescousse du jsessionid</title><link>https://javaetmoi.com/2013/05/mod_headers-rescousse-jsessionid-jboss/</link><pubDate>Thu, 23 May 2013 18:45:16 +0000</pubDate><guid isPermaLink="false">http://javaetmoi.com/?p=692</guid><description>Au cours de la migration d’une cinquantaine d’applications web de Websphere vers &lt;strong&gt;JBoss 5.1 EAP&lt;/strong&gt;, nous avons été confrontés à un problème de sécurité mis en évidence par l’infrastructure de pré-production : le firewall bloquait systématiquement toute requête comportant un &lt;strong&gt;jsessionid&lt;/strong&gt; dans l’ &lt;strong&gt;URL&lt;/strong&gt;.
Modifier les règles du firewall pour laisser passer ce type de requêtes aurait introduit une faille de sécurité exploitable par appropriation de session web. Cette faille nous a d’ailleurs été révélée en parallèle par l’outil d’audit de sécurité &lt;a href="http://www-03.ibm.com/software/products/us/en/appscan/"&gt;IBM AppScan&lt;/a&gt;.
Ce billet rappelle l’origine du problème et précise quelle solution a été employée pour le résoudre le plus rapidement possible.</description></item></channel></rss>