Derniers messages sur Zeste de Savoirhttps://zestedesavoir.com/forums/2022-01-09T11:41:19+01:00Les derniers messages parus sur le forum de Zeste de Savoir.Url qui but , message #2400702022-01-09T11:41:19+01:00Deuchnord/@Deuchnordhttps://zestedesavoir.com/forums/sujet/15977/url-qui-but/?page=1#p240070<p>Salut,</p>
<p>Le comportement de ton navigateur est en fait tout à fait normal, il s’agit d’une conversion en hexadécimal (demandée par le protocole HTTP, si je ne dis pas de bêtise) de la valeur que tu lui donnes :</p>
<ul>
<li>le symbole <code>%</code> permet d’indiquer que les deux caractères suivants doivent être interprétés comme un nombre hexadécimal</li>
<li>les deux caractères suivants donnent la valeur hexadécimale correspondant au caractère dans <a href="https://unicode-table.com/fr/">la table Unicode</a>.</li>
</ul>
<p>Ton problème ne vient donc pas de la façon dont ton URL est affichée dans la barre d’URL de ton navigateur, mais plutôt de la façon dont ton script JavaScript la lit. Peux-tu nous montrer le code qui te permet d’injecter à ta page le contenu de ton paramètre <code>keyword</code> ?</p>Url qui but , message #2400692022-01-09T11:29:48+01:00yanissoulapinou/@yanissoulapinouhttps://zestedesavoir.com/forums/sujet/15977/url-qui-but/?page=1#p240069<p>Bonjour, j’ai voulu essayer la faille XSS dans l’un de mes sites locales, voici mon url : "file:///Users/yannis/Desktop/Project/Demo.html?keyword="
J’ai donc ensuite rajouté du code, cela a donc donné : </p>
<p>file:///Users/yannis/Desktop/Project/Demo.html?keyword=<h1>Test<h1> </p>
<p>Cependant, après avoir entré l’url dans la barre de recherche, mon url s’est transformé en : </p>
<p>file:///Users/yannis/Desktop/Project/Demo.html?keyword=%3Ch1%3ETest%3Ch1%3E </p>
<p>Le test n’a donc évidemment pas marché car mon navigateur a exécuté "le lien transformé". Si quelqu’un pourrait m’aider pour que l’url ne se transforme plus, ce serait super gentil!
ps : je suis sur mac os, et cela fait moins de 3 mois que j’ai appris le language js, html etc, donc désolé si j’ai mal compris des notions.
Un grand merci !</p>XMLHttpRequest et envoi de cookie, message #2137882020-01-15T15:00:59+01:00mademlearn/@mademlearnhttps://zestedesavoir.com/forums/sujet/13489/xmlhttprequest-et-envoi-de-cookie/?page=1#p213788<p>J’ai repris à 0 à tête reposée et ça à fonctionné (tous les cookies sont envoyées). Et du coup j’ai pu exploiter ma XSS comme voulue.
Et non, le serveur de renvoi pas de header Access-Control-Allow-Credentials (mais si j’ai bien compris ça c’est pour gérer les CORS, c’est à dire quand on fait des requêtes sur des domaines différents, ce qui n’est pas le cas ici).</p>
<p>En tout cas, problem solved ! <img src="/static/smileys/smile.png" alt=":)" class="smiley"></p>XMLHttpRequest et envoi de cookie, message #2137282020-01-14T17:44:13+01:00ache/@achehttps://zestedesavoir.com/forums/sujet/13489/xmlhttprequest-et-envoi-de-cookie/?page=1#p213728<p>Bon, c’est un point que j’ai du mal à comprendre. Mais ton serveur envoye bien le header HTTP <a href="https://developer.mozilla.org/fr/docs/Web/HTTP/Headers/Access-Control-Allow-Credentials">Access-Control-Allow-Credentials</a> ?</p>XMLHttpRequest et envoi de cookie, message #2137242020-01-14T16:30:38+01:00amael/@amaelhttps://zestedesavoir.com/forums/sujet/13489/xmlhttprequest-et-envoi-de-cookie/?page=1#p213724<p>Salut,</p>
<p>Est-ce que d’autres cookies sont envoyés ? Et si oui, est-ce que le cookie de session existe avant l’envoi de la requète XHR ?</p>XMLHttpRequest et envoi de cookie, message #2137222020-01-14T15:51:00+01:00mademlearn/@mademlearnhttps://zestedesavoir.com/forums/sujet/13489/xmlhttprequest-et-envoi-de-cookie/?page=1#p213722<p>Bonjour,</p>
<p>Dans le cadre d’un bug bounty, j’ai trouvé une reflected XSS sur un paramètre POST.
Nommons le site vulnérable example.com pour plus de clarté.
Le endpoint vulnérable est <a href="https://example.com/statistics">https://example.com/statistics</a>.</p>
<p>Ce que j’aimerai faire via ma XSS, c’est effectuer une requête GET vers un second endpoint (qui nécessite d’être authentifié pour y accéder) : example.com/profil.
Pour ce faire j’ai utilisé XMLHttpRequest. Voilà le petit bout de code.</p>
<div class="hljs-code-div"><div class="hljs-line-numbers"><span></span><span></span><span></span><span></span><span></span><span></span><span></span><span></span><span></span><span></span><span></span><span></span></div><pre><code class="hljs language-js"><span class="hljs-keyword">var</span> xhr = <span class="hljs-keyword">new</span> XMLHttpRequest();
xhr.onreadystatechange = <span class="hljs-function"><span class="hljs-keyword">function</span>(<span class="hljs-params"></span>) </span>{
<span class="hljs-keyword">if</span> (xhr.readyState === <span class="hljs-number">4</span>) {
<span class="hljs-built_in">console</span>.log(xhr.response);
}
}
xhr.open(<span class="hljs-string">'GET'</span>, <span class="hljs-string">'https://example.com/profil/'</span>, <span class="hljs-literal">true</span>);
xhr.withCredentials = <span class="hljs-literal">true</span>;
xhr.send(<span class="hljs-literal">null</span>);
<span class="hljs-built_in">console</span>.log(xhr.reponse);
</code></pre></div>
<p>Donc sur mon serveur perso, j’héberge un bout de code javascript qui va automatiquement send une requête POST vers le endpoint vulnérable en envoyant ce code JS dans le paramètre vulnérable.</p>
<p>Je me suis créé un compte de test sur l’application, lorsque j’accède à mon serveur perso hébergeant cette page, je suis bien redirigé vers le site vulnérable est mon code est bien exécuté car en regardant l’onglet réseau de chromium, je vois bien une requête partir vers example.com/profil. Je suis à ce moment là bien authentifié.
Cependant, la requête qui part vers /profile ne contient pas mon cookie de session.</p>
<p>Ma question est, comment faire pour envoyer automatiquement le cookie de session via XMLHttpRequest ? <img src="/static/smileys/smile.png" alt=":)" class="smiley"> </p>Ne pas confondre faille par injection SQL et faille XSS, message #1774702018-04-12T19:04:43+02:00artragis/@artragishttps://zestedesavoir.com/forums/sujet/10493/ne-pas-confondre-faille-par-injection-sql-et-faille-xss/?page=1#p177470<p>Bonjour,</p>
<p>La bêta du contenu « Ne pas confondre faille par injection SQL et faille XSS » a été désactivée.</p>Ne pas confondre faille par injection SQL et faille XSS, message #1768042018-04-02T01:30:27+02:00Ymox/@Ymoxhttps://zestedesavoir.com/forums/sujet/10493/ne-pas-confondre-faille-par-injection-sql-et-faille-xss/?page=1#p176804<p>Bonjour les agrumes !</p>
<p>La bêta a été mise à jour et décante sa pulpe
à l’adresse suivante :</p>
<div align="center">
<p><a href="https://zestedesavoir.com/contenus/beta/2489/ne-pas-confondre-faille-par-injection-sql-et-faille-xss/">Ne pas confondre faille par injection SQL et faille XSS</a> </p>
</div>
<p>Merci d’avance pour vos commentaires.</p>Ne pas confondre faille par injection SQL et faille XSS, message #1768032018-04-02T01:16:29+02:00Ymox/@Ymoxhttps://zestedesavoir.com/forums/sujet/10493/ne-pas-confondre-faille-par-injection-sql-et-faille-xss/?page=1#p176803<p>Je comprends ton point de vue, et je vais mentionner ce principe en conclusion, comme piste pour aller plus loin.</p>
<p>Il semble que la plupart des personnes qui ont le genre de code présenté dans l’introduction l’ont <del>copié-collé (d’où ? Je tente de le découvrir au moment de poster ce message)</del> <em>appris avec PrimFx entre autres</em> et un peu adapté à leurs besoins, cet article va me servir d’explication longue que je n’aurai pas à copier-coller, juste à être la cible de liens. C’est donc pensé surtout pour des personnes qui ne comprennent pas ce principe et ne voudront probablement pas s’embarrasser de savoir qu’il existe, ni pourquoi, ni comment il s’applique, voulant faire leur code dans leur coin et apprendre juste le strict minimum pour que ça fonctionne. Ils ont peut-être entendu parler des failles par injection SQL ou/et des failles XSS, leur code (et les explications fournies avec ?) fait un amalgame que j’aimerais pouvoir éviter, et c’est là que s’arrête ma volonté pour cet article.<br>
Je ne me sens donc pas d’introduire pleinement ce principe dans cette publication, parce que ça me paraît bien plus vaste que ce que je voulais traiter. Je me vois mal mettre en avant le principe sans devoir expliquer ce qu’est une entrée et ce qu’est une sortie, pourquoi on filtre et qu’est-ce que ça représente concrètement, expliquer la notion d’échappement (explication qui est présente actuellement, bien que pas nommée ainsi et volontairement simplifiée).</p>Ne pas confondre faille par injection SQL et faille XSS, message #1767752018-04-01T00:30:47+02:00cepus/@cepushttps://zestedesavoir.com/forums/sujet/10493/ne-pas-confondre-faille-par-injection-sql-et-faille-xss/?page=1#p176775<p>Je trouve quand même mieux de nommer les choses, ça permet à certains de chercher plus loin, à d’autres de mieux retenir en groupant un ensemble de trucs sous un nom…</p>Ne pas confondre faille par injection SQL et faille XSS, message #1767732018-03-31T22:59:39+02:00Ymox/@Ymoxhttps://zestedesavoir.com/forums/sujet/10493/ne-pas-confondre-faille-par-injection-sql-et-faille-xss/?page=1#p176773<p>Salut !</p>
<p>Je n’ai pas pensé à donner le nom du principe, mais plus à en expliquer la source, plus ou moins directement. Le hic, c’est que certaines personnes pensent que de PHP vers la base de données, c’est une sortie…</p>Ne pas confondre faille par injection SQL et faille XSS, message #1767462018-03-31T10:03:48+02:00cepus/@cepushttps://zestedesavoir.com/forums/sujet/10493/ne-pas-confondre-faille-par-injection-sql-et-faille-xss/?page=1#p176746<p>Salut !</p>
<p>J’ai l’impression que tu brodes autour du principe <em>filter input escape output</em>, une raison de ne pas le nommer ? Pour moi c’est une façon efficace de présenter, expliquer et retenir la chose. </p>Ne pas confondre faille par injection SQL et faille XSS, message #1767432018-03-31T04:07:05+02:00Ymox/@Ymoxhttps://zestedesavoir.com/forums/sujet/10493/ne-pas-confondre-faille-par-injection-sql-et-faille-xss/?page=1#p176743<p>Tout le monde se secoue ! <img alt=":D" src="/static/smileys/heureux.png"></p>
<p>J’ai commencé (il y a 26 minutes) la rédaction d’un article au doux nom
de « Ne pas confondre faille par injection SQL et faille XSS » et j’ai pour objectif de proposer en validation
un texte aux petits oignons. Je fais donc appel à votre bonté sans
limites pour dénicher le moindre pépin, que ce soit à propos
du fond ou de la forme. Vous pourrez consulter la bêta à votre guise à
l’adresse suivante :</p>
<div align="center">
<p><del><a href="#">À présent, c’est à vous !</a></del> </p>
</div>
<p>Merci !</p>
<h4>Edit</h4>
<p>L’article a été publié, vous le retrouverez <a href="/articles/2489/ne-pas-confondre-faille-par-injection-sql-et-faille-xss/">ici</a></p>Securiser $_POST wysiwyg html, message #438522015-02-15T19:12:56+01:00Ajabep/@Ajabephttps://zestedesavoir.com/forums/sujet/2338/securiser-_post-wysiwyg-html/?page=1#p43852<p>En fait, il s'agit de la faille CSRF et non XSS <img alt="^^" src="/static/smileys/hihi.png"></p>
<figure><blockquote>
<ol>
<li>Peut-être mettre en place un TOKEN (contre la faille XSRF).
</li>
</ol>
</blockquote>
<figcaption><p><a href="http://zestedesavoir.com/forums/sujet/2338/securiser-_post-wysiwyg-html/?page=1#p41934">A-312</a></p></figcaption></figure><p>En effet, pour cela, la meilleure solution que je connaisse est de générer des tokens.</p>
<p>Il s'agit de chaine de caractères aléatoires pour pouvoir confirmer que la demande est légitime. Ainsi, une simple requête sur <em>/deconnexion.php</em> ne ferra rien s'il n'y a pas de token en paramètre.</p>
<p>Pour gérer tes tokens, tu peux le faire toi même, ou prendre une librairie qui le fait pour toi.</p>
<p>Il y a quelques temps, j'avais fait une <a href="https://github.com/ajabep/TokenAPI">librairie</a> pour gérer ça. Le code étant sale, hésites pas à le modifier <img alt=";)" src="/static/smileys/clin.png"></p>Securiser $_POST wysiwyg html, message #419762015-02-01T21:58:04+01:00anonyme/@anonymehttps://zestedesavoir.com/forums/sujet/2338/securiser-_post-wysiwyg-html/?page=1#p41976<p>Si HTMLPurifier ne te conviens pas lis cette article :<br>
<a href="http://www.weirdog.com/blog/php/un-parser-html-des-plus-leger.html">http://www.weirdog.com/blog/php/un-parser-html-des-plus-leger.html</a></p>
<p>Sinon tu dois pouvoir interdire la balise img, c'est à toi de voir selon ton besoin.</p>Securiser $_POST wysiwyg html, message #419482015-02-01T18:39:10+01:00Stoakes/@Stoakeshttps://zestedesavoir.com/forums/sujet/2338/securiser-_post-wysiwyg-html/?page=1#p41948<p>Si je supprimais tous les attributs src des balises,ne serait-ce pas plus simple ?</p>
<p>Par contre j'ai lu que les regex n'étaient pas adaptées pour parser du html et qu'il valait mieux utiliser DOMdocument. Confirmez vous ça ? Est-ce que DomDocument est moins gourmand que les regex ?</p>Securiser $_POST wysiwyg html, message #419392015-02-01T18:11:44+01:00anonyme/@anonymehttps://zestedesavoir.com/forums/sujet/2338/securiser-_post-wysiwyg-html/?page=1#p41939<p>Je viens d'essayer et ça fonctionne très bien avec l'URL Rewriting, je pense que ça doit fonctionner aussi bien en modifiant le fileType.</p>
<p>On n'est pas obligé de créer un fichier php, on peut créer directement une redirection dans un fichier .htacess.</p>
<table class="codehilitetable"><tr><td class="linenos"><div class="linenodiv"><pre>1
2
3</pre></div></td><td class="code"><div class="codehilite"><pre><span class="nb">RewriteEngine</span> <span class="k">On</span>
<span class="nb">RewriteRule</span> ^artragis\.png$ https://zestedesavoir.com/media/galleries/426/56dc4a1e-416b-4a9d-830d-95b45d58a17a.png [R=301,L]
<span class="nb">RewriteRule</span> ^A312\.png$ move.php [L]
</pre></div>
</td></tr></table>Securiser $_POST wysiwyg html, message #419362015-02-01T17:58:20+01:00artragis/@artragishttps://zestedesavoir.com/forums/sujet/2338/securiser-_post-wysiwyg-html/?page=1#p41936<p>A-312 : il me semble que si puisque le navigateur ne redirigera pas l'image s'il reçoit un move sur un img.</p>Securiser $_POST wysiwyg html, message #419342015-02-01T17:37:55+01:00anonyme/@anonymehttps://zestedesavoir.com/forums/sujet/2338/securiser-_post-wysiwyg-html/?page=1#p41934<p>La vrai solution ne serait-elle pas de corriger le problème directement sur la page de déconnexion ?</p>
<ol>
<li>Passer en POST sur la déconnexion.</li>
<li>Peut-être mettre en place un TOKEN (contre la faille XSRF).</li>
</ol>
<p>Je serais intéressé de savoir si ce filtre fonctionne, surtout qu'il ne permettrait pas de bloquer ceci :</p>
<table class="codehilitetable"><tr><td class="linenos"><div class="linenodiv"><pre>1
2
3
4
5
6
7</pre></div></td><td class="code"><div class="codehilite"><pre><span class="cp"><?php</span>
<span class="cm">/* http://siteuser.com/image.png */</span>
<span class="c1">// Permanent redirection</span>
<span class="nb">header</span><span class="p">(</span><span class="s2">"HTTP/1.1 301 Moved Permanently"</span><span class="p">);</span>
<span class="nb">header</span><span class="p">(</span><span class="s2">"Location: http://sitede.stoakes.fr/deconnexion.php"</span><span class="p">);</span>
<span class="k">exit</span><span class="p">();</span>
<span class="cp">?></span><span class="x"></span>
</pre></div>
</td></tr></table>Securiser $_POST wysiwyg html, message #418792015-02-01T13:13:20+01:00artragis/@artragishttps://zestedesavoir.com/forums/sujet/2338/securiser-_post-wysiwyg-html/?page=1#p41879<blockquote>
<p>escape_string c'est juste pour ne pas avoir de souçis lors de l'insertion.</p>
</blockquote>
<p>HTML purifier = faille XSS = uniquement à l'affichage, pas à l'insertion en base de données. Effectivement, c'est mysqli_real_escape_string qu'il faut utiliser pour la bdd.</p>
<blockquote>
<p>Le problème vient du fait que les utilisateurs peuvent faire charger au lecteur, via l'attribut src de l'image, n'importe quelle page du site.</p>
</blockquote>
<p>il faut comprendre que l'attribut src fait que ton navigateur envoie directement une requête http vers l'adresse renseignée. Ce n'est pas un "problème" c'est une feature. Il faut donc interdire des src avec un fichier .php.</p>Securiser $_POST wysiwyg html, message #418772015-02-01T12:44:14+01:00Stoakes/@Stoakeshttps://zestedesavoir.com/forums/sujet/2338/securiser-_post-wysiwyg-html/?page=1#p41877<p>escape_string c'est juste pour ne pas avoir de souçis lors de l'insertion.</p>
<p>J'ai changé la config d'HTMlPurifier, mais <img src="/deconnexion.php"> passe toujours à travers.</p>
<figure><blockquote>
<p>je te propose d'empêcher toutes les images qui se terminent par ".php"
</p>
</blockquote>
<figcaption><p><a href="http://zestedesavoir.com/forums/sujet/2338/securiser-_post-wysiwyg-html/?page=1#p41875">artragis</a></p></figcaption></figure><p>Désolé je ne comprends pas. Le problème vient du fait que les utilisateurs peuvent faire charger au lecteur, via l'attribut src de l'image, n'importe quelle page du site.</p>