Le 26/03/2021 Í 16:44, "Olivier Miakinen" a écrit :
J'avais oublié que SeaMonkey fait une première interprétation avant envoi.
Alors d'ici on ne voit rien, ou juste de la bouillie :)
Olivier Miakinen
Le 26/03/2021 16:45, Elephant Man a écrit :
Le 26/03/2021 Í 16:44, "Olivier Miakinen" a écrit :
J'avais oublié que SeaMonkey fait une première interprétation avant envoi.
Alors d'ici on ne voit rien, ou juste de la bouillie :)
Visiblement Nemo, tout comme SeaMonkey, a quand même interprété certaines parties du sujet (en fait la partie du milieu), alors que tout était incorrect. Je pense que seul NewsPortal aura tout bon en ne décodant rien et en affichant : =?us_ascii?Q?Nouveau te?= =?iso-8859-1?q?st avec xa?= =?iso-8888-8?Q?nanews?=. Au contraire, Xananews a tout accepté comme du bon pain, il affiche : Nouveau test avec xananews. -- Olivier Miakinen
Le 26/03/2021 16:45, Elephant Man a écrit :
Le 26/03/2021 Í 16:44, "Olivier Miakinen" a écrit :
J'avais oublié que SeaMonkey fait une première interprétation avant
envoi.
Alors d'ici on ne voit rien, ou juste de la bouillie :)
Visiblement Nemo, tout comme SeaMonkey, a quand même interprété certaines
parties du sujet (en fait la partie du milieu), alors que tout était
incorrect. Je pense que seul NewsPortal aura tout bon en ne décodant
rien et en affichant : =?us_ascii?Q?Nouveau te?= =?iso-8859-1?q?st avec
xa?= =?iso-8888-8?Q?nanews?=.
Au contraire, Xananews a tout accepté comme du bon pain, il affiche :
Nouveau test avec xananews.
Le 26/03/2021 Í 16:44, "Olivier Miakinen" a écrit :
J'avais oublié que SeaMonkey fait une première interprétation avant envoi.
Alors d'ici on ne voit rien, ou juste de la bouillie :)
Visiblement Nemo, tout comme SeaMonkey, a quand même interprété certaines parties du sujet (en fait la partie du milieu), alors que tout était incorrect. Je pense que seul NewsPortal aura tout bon en ne décodant rien et en affichant : =?us_ascii?Q?Nouveau te?= =?iso-8859-1?q?st avec xa?= =?iso-8888-8?Q?nanews?=. Au contraire, Xananews a tout accepté comme du bon pain, il affiche : Nouveau test avec xananews. -- Olivier Miakinen
Elephant Man
Le 26/03/2021 Í 16:53, Olivier Miakinen a écrit :
Visiblement Nemo, tout comme SeaMonkey, a quand même interprété certaines parties du sujet (en fait la partie du milieu), alors que tout était incorrect. Je pense que seul NewsPortal aura tout bon en ne décodant rien et en affichant : =?us_ascii?Q?Nouveau te?= =?iso-8859-1?q?st avec xa?= =?iso-8888-8?Q?nanews?=.
Ce qui il faut bien l'avouer n'est pas un énorme progrès.
Au contraire, Xananews a tout accepté comme du bon pain, il affiche : Nouveau test avec xananews.
Encore heureux qu'il affiche ce qu'il envoie, mais je te l'ai dit, c'est un très mauvais lecteur. Par contre comme les sources sont libres, il y a une petite chance que des gens corrigent certains bugs.
Le 26/03/2021 Í 16:53, Olivier Miakinen a écrit :
Visiblement Nemo, tout comme SeaMonkey, a quand même interprété certaines
parties du sujet (en fait la partie du milieu), alors que tout était
incorrect. Je pense que seul NewsPortal aura tout bon en ne décodant
rien et en affichant : =?us_ascii?Q?Nouveau te?= =?iso-8859-1?q?st avec
xa?= =?iso-8888-8?Q?nanews?=.
Ce qui il faut bien l'avouer n'est pas un énorme progrès.
Au contraire, Xananews a tout accepté comme du bon pain, il affiche :
Nouveau test avec xananews.
Encore heureux qu'il affiche ce qu'il envoie, mais je te l'ai dit, c'est
un très mauvais lecteur. Par contre comme les sources sont libres, il y a
une petite chance que des gens corrigent certains bugs.
Visiblement Nemo, tout comme SeaMonkey, a quand même interprété certaines parties du sujet (en fait la partie du milieu), alors que tout était incorrect. Je pense que seul NewsPortal aura tout bon en ne décodant rien et en affichant : =?us_ascii?Q?Nouveau te?= =?iso-8859-1?q?st avec xa?= =?iso-8888-8?Q?nanews?=.
Ce qui il faut bien l'avouer n'est pas un énorme progrès.
Au contraire, Xananews a tout accepté comme du bon pain, il affiche : Nouveau test avec xananews.
Encore heureux qu'il affiche ce qu'il envoie, mais je te l'ai dit, c'est un très mauvais lecteur. Par contre comme les sources sont libres, il y a une petite chance que des gens corrigent certains bugs.
Olivier Miakinen
Le 26/03/2021 16:58, Elephant Man a écrit :
[...] Je pense que seul NewsPortal aura tout bon en ne décodant rien et en affichant : =?us_ascii?Q?Nouveau te?= =?iso-8859-1?q?st avec xa?= =?iso-8888-8?Q?nanews?=.
Ce qui il faut bien l'avouer n'est pas un énorme progrès.
Permets-moi de ne pas être d'accord. D'une part c'est un excellent détecteur de bugs, et d'autre part ça lui permet d'être immunisé contre certaines bidouille qui pourraient être utilisées par des spammeurs pour trafiquer les entêtes. Lorsque l'encodage est correct et non malicieux, NewsPortal le décode aussi bien que les autres. -- Olivier Miakinen
Le 26/03/2021 16:58, Elephant Man a écrit :
[...] Je pense que seul NewsPortal aura tout bon en ne décodant
rien et en affichant : =?us_ascii?Q?Nouveau te?= =?iso-8859-1?q?st avec
xa?= =?iso-8888-8?Q?nanews?=.
Ce qui il faut bien l'avouer n'est pas un énorme progrès.
Permets-moi de ne pas être d'accord. D'une part c'est un excellent
détecteur de bugs, et d'autre part ça lui permet d'être immunisé
contre certaines bidouille qui pourraient être utilisées par des
spammeurs pour trafiquer les entêtes.
Lorsque l'encodage est correct et non malicieux, NewsPortal le décode
aussi bien que les autres.
[...] Je pense que seul NewsPortal aura tout bon en ne décodant rien et en affichant : =?us_ascii?Q?Nouveau te?= =?iso-8859-1?q?st avec xa?= =?iso-8888-8?Q?nanews?=.
Ce qui il faut bien l'avouer n'est pas un énorme progrès.
Permets-moi de ne pas être d'accord. D'une part c'est un excellent détecteur de bugs, et d'autre part ça lui permet d'être immunisé contre certaines bidouille qui pourraient être utilisées par des spammeurs pour trafiquer les entêtes. Lorsque l'encodage est correct et non malicieux, NewsPortal le décode aussi bien que les autres. -- Olivier Miakinen
yamo'
Salut, Ceci n'est pas un test ;) Olivier Miakinen a tapoté le 26/03/2021 17:13:
Le 26/03/2021 16:58, Elephant Man a écrit :
[...] Je pense que seul NewsPortal aura tout bon en ne décodant rien et en affichant : =?us_ascii?Q?Nouveau te?= =?iso-8859-1?q?st avec xa?= =?iso-8888-8?Q?nanews?=.
Ce qui il faut bien l'avouer n'est pas un énorme progrès.
Ici j'ai : Re: =?us_ascii?Q?Nouveau te?=st avec xa=?iso-8888-8?Q?nanews?
Permets-moi de ne pas être d'accord. D'une part c'est un excellent détecteur de bugs, et d'autre part ça lui permet d'être immunisé contre certaines bidouille qui pourraient être utilisées par des spammeurs pour trafiquer les entêtes.
Si tu as des pistes de lecture (copie fr.comp.securite et php... ), ça m'intéresse. En effet, je ne vois pas qu'elle est la faille possible avec le champs Subject... J'avais des pistes valables en java mais je ne sais pas si c'est applicable en php.
Lorsque l'encodage est correct et non malicieux, NewsPortal le décode aussi bien que les autres.
Pour la petite histoire quand j'aurais une alimentation dédiée Í mon nouveau raspberry pi4 (il squatte de temps en temps celle de mon smartphone), je testerais Newsportal sur php 7.4 (debian testing). -- Stéphane
Salut,
Ceci n'est pas un test ;)
Olivier Miakinen a tapoté le 26/03/2021 17:13:
Le 26/03/2021 16:58, Elephant Man a écrit :
[...] Je pense que seul NewsPortal aura tout bon en ne décodant
rien et en affichant : =?us_ascii?Q?Nouveau te?= =?iso-8859-1?q?st avec
xa?= =?iso-8888-8?Q?nanews?=.
Ce qui il faut bien l'avouer n'est pas un énorme progrès.
Ici j'ai :
Re: =?us_ascii?Q?Nouveau te?=st avec xa=?iso-8888-8?Q?nanews?
Permets-moi de ne pas être d'accord. D'une part c'est un excellent
détecteur de bugs, et d'autre part ça lui permet d'être immunisé
contre certaines bidouille qui pourraient être utilisées par des
spammeurs pour trafiquer les entêtes.
Si tu as des pistes de lecture (copie fr.comp.securite et php...
), ça m'intéresse. En effet, je ne vois pas qu'elle est la faille
possible avec le champs Subject...
J'avais des pistes valables en java mais je ne sais pas si c'est
applicable en php.
Lorsque l'encodage est correct et non malicieux, NewsPortal le décode
aussi bien que les autres.
Pour la petite histoire quand j'aurais une alimentation dédiée Í mon
nouveau raspberry pi4 (il squatte de temps en temps celle de mon
smartphone), je testerais Newsportal sur php 7.4 (debian testing).
Salut, Ceci n'est pas un test ;) Olivier Miakinen a tapoté le 26/03/2021 17:13:
Le 26/03/2021 16:58, Elephant Man a écrit :
[...] Je pense que seul NewsPortal aura tout bon en ne décodant rien et en affichant : =?us_ascii?Q?Nouveau te?= =?iso-8859-1?q?st avec xa?= =?iso-8888-8?Q?nanews?=.
Ce qui il faut bien l'avouer n'est pas un énorme progrès.
Ici j'ai : Re: =?us_ascii?Q?Nouveau te?=st avec xa=?iso-8888-8?Q?nanews?
Permets-moi de ne pas être d'accord. D'une part c'est un excellent détecteur de bugs, et d'autre part ça lui permet d'être immunisé contre certaines bidouille qui pourraient être utilisées par des spammeurs pour trafiquer les entêtes.
Si tu as des pistes de lecture (copie fr.comp.securite et php... ), ça m'intéresse. En effet, je ne vois pas qu'elle est la faille possible avec le champs Subject... J'avais des pistes valables en java mais je ne sais pas si c'est applicable en php.
Lorsque l'encodage est correct et non malicieux, NewsPortal le décode aussi bien que les autres.
Pour la petite histoire quand j'aurais une alimentation dédiée Í mon nouveau raspberry pi4 (il squatte de temps en temps celle de mon smartphone), je testerais Newsportal sur php 7.4 (debian testing). -- Stéphane
Stéphane CARPENTIER
Le 26-03-2021, Olivier Miakinen <om+ a écrit :
J'avais oublié que SeaMonkey fait une première interprétation avant envoi.
Je ne vois rien de spécial avec ton message. C'est la réponse d'EM qui m'a montré que le titre pouvait poser problème Í certains lecteurs. -- Si vous avez du temps Í perdre : https://scarpet42.gitlab.io
Le 26-03-2021, Olivier Miakinen <om+alphanet.ch@miakinen.net> a écrit :
J'avais oublié que SeaMonkey fait une première interprétation avant
envoi.
Je ne vois rien de spécial avec ton message. C'est la réponse d'EM qui
m'a montré que le titre pouvait poser problème Í certains lecteurs.
--
Si vous avez du temps Í perdre :
https://scarpet42.gitlab.io
J'avais oublié que SeaMonkey fait une première interprétation avant envoi.
Je ne vois rien de spécial avec ton message. C'est la réponse d'EM qui m'a montré que le titre pouvait poser problème Í certains lecteurs. -- Si vous avez du temps Í perdre : https://scarpet42.gitlab.io
Olivier Miakinen
Le 27/03/2021 16:46, Stéphane CARPENTIER a écrit :
Le 26-03-2021, Olivier Miakinen <om+ a écrit :
J'avais oublié que SeaMonkey fait une première interprétation avant envoi.
Je ne vois rien de spécial avec ton message. C'est la réponse d'EM qui m'a montré que le titre pouvait poser problème Í certains lecteurs.
C'était un test pour moi, mais je veux bien expliquer en quoi ce titre était complètement incorrect, pour quatre raisons. =?us_ascii?Q?Nouveau te?1) le charset us_ascii n'existe pas, même si en l'occurrence c'était une erreur involontaire de ma part (confusion avec us-ascii) 2) il y a un caractère espace, du coup ce sont deux simples mots « =?us_ascii?Q?Nouveau » et « te?= » au lieu d'un encoded-word MIME. =?iso-8859-1?q?st avec xa?3) Ici il y a deux espaces, donc trois mots simples au lieu d'un encoded-word MIME. =?iso-8888-8?Q?nanews?4) Le charset iso-8888-8 n'existe pas, et n'a même aucun presque synonyme. Je ne vois pas comment on pourrait décoder le e dans ces conditions. Références : https://www.iana.org/assignments/character-sets/character-sets.xhtml https://tools.ietf.org/html/rfc2047 -- Olivier Miakinen
Le 27/03/2021 16:46, Stéphane CARPENTIER a écrit :
Le 26-03-2021, Olivier Miakinen <om+alphanet.ch@miakinen.net> a écrit :
J'avais oublié que SeaMonkey fait une première interprétation avant
envoi.
Je ne vois rien de spécial avec ton message. C'est la réponse d'EM qui
m'a montré que le titre pouvait poser problème Í certains lecteurs.
C'était un test pour moi, mais je veux bien expliquer en quoi ce titre
était complètement incorrect, pour quatre raisons.
=?us_ascii?Q?Nouveau te?1) le charset us_ascii n'existe pas, même si en l'occurrence c'était
une erreur involontaire de ma part (confusion avec us-ascii)
2) il y a un caractère espace, du coup ce sont deux simples mots
« =?us_ascii?Q?Nouveau » et « te?= » au lieu d'un encoded-word
MIME.
=?iso-8859-1?q?st avec xa?3) Ici il y a deux espaces, donc trois mots simples au lieu d'un
encoded-word MIME.
=?iso-8888-8?Q?nanews?4) Le charset iso-8888-8 n'existe pas, et n'a même aucun presque
synonyme. Je ne vois pas comment on pourrait décoder le e dans
ces conditions.
Le 27/03/2021 16:46, Stéphane CARPENTIER a écrit :
Le 26-03-2021, Olivier Miakinen <om+ a écrit :
J'avais oublié que SeaMonkey fait une première interprétation avant envoi.
Je ne vois rien de spécial avec ton message. C'est la réponse d'EM qui m'a montré que le titre pouvait poser problème Í certains lecteurs.
C'était un test pour moi, mais je veux bien expliquer en quoi ce titre était complètement incorrect, pour quatre raisons. =?us_ascii?Q?Nouveau te?1) le charset us_ascii n'existe pas, même si en l'occurrence c'était une erreur involontaire de ma part (confusion avec us-ascii) 2) il y a un caractère espace, du coup ce sont deux simples mots « =?us_ascii?Q?Nouveau » et « te?= » au lieu d'un encoded-word MIME. =?iso-8859-1?q?st avec xa?3) Ici il y a deux espaces, donc trois mots simples au lieu d'un encoded-word MIME. =?iso-8888-8?Q?nanews?4) Le charset iso-8888-8 n'existe pas, et n'a même aucun presque synonyme. Je ne vois pas comment on pourrait décoder le e dans ces conditions. Références : https://www.iana.org/assignments/character-sets/character-sets.xhtml https://tools.ietf.org/html/rfc2047 -- Olivier Miakinen
Stéphane CARPENTIER
Le 27-03-2021, Olivier Miakinen <om+ a écrit :
Le 27/03/2021 16:46, Stéphane CARPENTIER a écrit :
Le 26-03-2021, Olivier Miakinen <om+ a écrit :
J'avais oublié que SeaMonkey fait une première interprétation avant envoi.
Je ne vois rien de spécial avec ton message. C'est la réponse d'EM qui m'a montré que le titre pouvait poser problème Í certains lecteurs.
C'était un test pour moi, mais je veux bien expliquer en quoi ce titre était complètement incorrect, pour quatre raisons.
Je me doutais que c'était un test pour toi, mais je croyais que tu voulais savoir comment les lecteurs le voyaient alors vu que je n'ai pas vu de réponse en slrn j'ai répondu.
=?us_ascii?Q?Nouveau te?
Avec slrn, je ne vois pas ça, je vois juste le titre propre sans espace surnuméraire ni rien. La seule définition d'encodage que je vois dans tes en-têtes, c'est utf8. Je croyais que tu avais utilisé un caractère genre cyrillique qui ressemblait Í un caractère latin et qui en gênait certains tout en étant transparent pour d'autres. -- Si vous avez du temps Í perdre : https://scarpet42.gitlab.io
Le 27-03-2021, Olivier Miakinen <om+news@miakinen.net> a écrit :
Le 27/03/2021 16:46, Stéphane CARPENTIER a écrit :
Le 26-03-2021, Olivier Miakinen <om+alphanet.ch@miakinen.net> a écrit :
J'avais oublié que SeaMonkey fait une première interprétation avant
envoi.
Je ne vois rien de spécial avec ton message. C'est la réponse d'EM qui
m'a montré que le titre pouvait poser problème Í certains lecteurs.
C'était un test pour moi, mais je veux bien expliquer en quoi ce titre
était complètement incorrect, pour quatre raisons.
Je me doutais que c'était un test pour toi, mais je croyais que tu
voulais savoir comment les lecteurs le voyaient alors vu que je n'ai pas
vu de réponse en slrn j'ai répondu.
=?us_ascii?Q?Nouveau te?
Avec slrn, je ne vois pas ça, je vois juste le titre propre sans espace
surnuméraire ni rien. La seule définition d'encodage que je vois dans
tes en-têtes, c'est utf8. Je croyais que tu avais utilisé un caractère
genre cyrillique qui ressemblait Í un caractère latin et qui en gênait
certains tout en étant transparent pour d'autres.
--
Si vous avez du temps Í perdre :
https://scarpet42.gitlab.io
Le 27/03/2021 16:46, Stéphane CARPENTIER a écrit :
Le 26-03-2021, Olivier Miakinen <om+ a écrit :
J'avais oublié que SeaMonkey fait une première interprétation avant envoi.
Je ne vois rien de spécial avec ton message. C'est la réponse d'EM qui m'a montré que le titre pouvait poser problème Í certains lecteurs.
C'était un test pour moi, mais je veux bien expliquer en quoi ce titre était complètement incorrect, pour quatre raisons.
Je me doutais que c'était un test pour toi, mais je croyais que tu voulais savoir comment les lecteurs le voyaient alors vu que je n'ai pas vu de réponse en slrn j'ai répondu.
=?us_ascii?Q?Nouveau te?
Avec slrn, je ne vois pas ça, je vois juste le titre propre sans espace surnuméraire ni rien. La seule définition d'encodage que je vois dans tes en-têtes, c'est utf8. Je croyais que tu avais utilisé un caractère genre cyrillique qui ressemblait Í un caractère latin et qui en gênait certains tout en étant transparent pour d'autres. -- Si vous avez du temps Í perdre : https://scarpet42.gitlab.io
Olivier Miakinen
Le 27/03/2021 10:37, yamo' a écrit :
[...] et d'autre part ça lui permet d'être immunisé contre certaines bidouille qui pourraient être utilisées par des spammeurs pour trafiquer les entêtes.
Si tu as des pistes de lecture (copie fr.comp.securite et php... ), ça m'intéresse. En effet, je ne vois pas qu'elle est la faille possible avec le champs Subject...
À vrai dire je n'en vois pas non plus, mais justement il m'est plusieurs fois arrivé de lire que tel ou tel défaut de contrÍ´le pouvait vraiment servir Í un attaquant, alors que je n'avais pas imaginé que c'était possible ! Du coup maintenant je considère Í priori tout ce qui n'est pas prévu comme étant une faille potentielle. Bon, déjÍ il y a peut-être une possibilité de phishing, ainsi que l'a imaginé Stéphane Carpentier avec un caractère non-latin ressemblant Í un caractère latin. -- Olivier Miakinen
Le 27/03/2021 10:37, yamo' a écrit :
[...] et d'autre part ça lui permet d'être immunisé
contre certaines bidouille qui pourraient être utilisées par des
spammeurs pour trafiquer les entêtes.
Si tu as des pistes de lecture (copie fr.comp.securite et php...
), ça m'intéresse. En effet, je ne vois pas qu'elle est la faille
possible avec le champs Subject...
À vrai dire je n'en vois pas non plus, mais justement il m'est plusieurs
fois arrivé de lire que tel ou tel défaut de contrÍ´le pouvait vraiment
servir Í un attaquant, alors que je n'avais pas imaginé que c'était
possible ! Du coup maintenant je considère Í priori tout ce qui n'est pas
prévu comme étant une faille potentielle.
Bon, déjÍ il y a peut-être une possibilité de phishing, ainsi que l'a
imaginé Stéphane Carpentier avec un caractère non-latin ressemblant Í
un caractère latin.
[...] et d'autre part ça lui permet d'être immunisé contre certaines bidouille qui pourraient être utilisées par des spammeurs pour trafiquer les entêtes.
Si tu as des pistes de lecture (copie fr.comp.securite et php... ), ça m'intéresse. En effet, je ne vois pas qu'elle est la faille possible avec le champs Subject...
À vrai dire je n'en vois pas non plus, mais justement il m'est plusieurs fois arrivé de lire que tel ou tel défaut de contrÍ´le pouvait vraiment servir Í un attaquant, alors que je n'avais pas imaginé que c'était possible ! Du coup maintenant je considère Í priori tout ce qui n'est pas prévu comme étant une faille potentielle. Bon, déjÍ il y a peut-être une possibilité de phishing, ainsi que l'a imaginé Stéphane Carpentier avec un caractère non-latin ressemblant Í un caractère latin. -- Olivier Miakinen
Stéphane CARPENTIER
Le 27-03-2021, Olivier Miakinen <om+ a écrit :
Le 27/03/2021 10:37, yamo' a écrit :
[...] et d'autre part ça lui permet d'être immunisé contre certaines bidouille qui pourraient être utilisées par des spammeurs pour trafiquer les entêtes.
Si tu as des pistes de lecture (copie fr.comp.securite et php... ), ça m'intéresse. En effet, je ne vois pas qu'elle est la faille possible avec le champs Subject...
À vrai dire je n'en vois pas non plus, mais justement il m'est plusieurs fois arrivé de lire que tel ou tel défaut de contrÍ´le pouvait vraiment servir Í un attaquant, alors que je n'avais pas imaginé que c'était possible ! Du coup maintenant je considère Í priori tout ce qui n'est pas prévu comme étant une faille potentielle.
Pour moi, le but de la bidouille de caractères spéciaux pour une attaque, c'est quand ils sont interprétés que je vois une utilité. Mais vu que le sujet c'est juste de l'affichage, ça me semble délicat d'obtenir quelque chose d'intéressant. Les champs Reply-To ou Followup-To me semblent plus intéressants Í attaquer puisque le lecteur va exécuter des actions en fonction de ce qu'il y a dedans. Même si je vois mal comment ils pourraient être utilisés sans exploiter une faille du lecteur. De ce que j'ai vu, jouer avec les encodages, c'est surtout pour essayer de bypasser les filtres anti-XSS et anti SQL injection.
Bon, déjÍ il y a peut-être une possibilité de phishing, ainsi que l'a imaginé Stéphane Carpentier avec un caractère non-latin ressemblant Í un caractère latin.
Ça, c'est plus facile de le mettre dans le corps du mail et d'attendre que quelqu'un clique. Dans l'en-tête, c'est rare de voir une url et ça devrait rendre les gens méfiants. -- Si vous avez du temps Í perdre : https://scarpet42.gitlab.io
Le 27-03-2021, Olivier Miakinen <om+news@miakinen.net> a écrit :
Le 27/03/2021 10:37, yamo' a écrit :
[...] et d'autre part ça lui permet d'être immunisé
contre certaines bidouille qui pourraient être utilisées par des
spammeurs pour trafiquer les entêtes.
Si tu as des pistes de lecture (copie fr.comp.securite et php...
), ça m'intéresse. En effet, je ne vois pas qu'elle est la faille
possible avec le champs Subject...
À vrai dire je n'en vois pas non plus, mais justement il m'est plusieurs
fois arrivé de lire que tel ou tel défaut de contrÍ´le pouvait vraiment
servir Í un attaquant, alors que je n'avais pas imaginé que c'était
possible ! Du coup maintenant je considère Í priori tout ce qui n'est pas
prévu comme étant une faille potentielle.
Pour moi, le but de la bidouille de caractères spéciaux pour une
attaque, c'est quand ils sont interprétés que je vois une utilité. Mais
vu que le sujet c'est juste de l'affichage, ça me semble délicat
d'obtenir quelque chose d'intéressant.
Les champs Reply-To ou Followup-To me semblent plus intéressants Í
attaquer puisque le lecteur va exécuter des actions en fonction de ce
qu'il y a dedans. Même si je vois mal comment ils pourraient être
utilisés sans exploiter une faille du lecteur.
De ce que j'ai vu, jouer avec les encodages, c'est surtout pour essayer
de bypasser les filtres anti-XSS et anti SQL injection.
Bon, déjÍ il y a peut-être une possibilité de phishing, ainsi que l'a
imaginé Stéphane Carpentier avec un caractère non-latin ressemblant Í
un caractère latin.
Ça, c'est plus facile de le mettre dans le corps du mail et d'attendre
que quelqu'un clique. Dans l'en-tête, c'est rare de voir une url et ça
devrait rendre les gens méfiants.
--
Si vous avez du temps Í perdre :
https://scarpet42.gitlab.io
[...] et d'autre part ça lui permet d'être immunisé contre certaines bidouille qui pourraient être utilisées par des spammeurs pour trafiquer les entêtes.
Si tu as des pistes de lecture (copie fr.comp.securite et php... ), ça m'intéresse. En effet, je ne vois pas qu'elle est la faille possible avec le champs Subject...
À vrai dire je n'en vois pas non plus, mais justement il m'est plusieurs fois arrivé de lire que tel ou tel défaut de contrÍ´le pouvait vraiment servir Í un attaquant, alors que je n'avais pas imaginé que c'était possible ! Du coup maintenant je considère Í priori tout ce qui n'est pas prévu comme étant une faille potentielle.
Pour moi, le but de la bidouille de caractères spéciaux pour une attaque, c'est quand ils sont interprétés que je vois une utilité. Mais vu que le sujet c'est juste de l'affichage, ça me semble délicat d'obtenir quelque chose d'intéressant. Les champs Reply-To ou Followup-To me semblent plus intéressants Í attaquer puisque le lecteur va exécuter des actions en fonction de ce qu'il y a dedans. Même si je vois mal comment ils pourraient être utilisés sans exploiter une faille du lecteur. De ce que j'ai vu, jouer avec les encodages, c'est surtout pour essayer de bypasser les filtres anti-XSS et anti SQL injection.
Bon, déjÍ il y a peut-être une possibilité de phishing, ainsi que l'a imaginé Stéphane Carpentier avec un caractère non-latin ressemblant Í un caractère latin.
Ça, c'est plus facile de le mettre dans le corps du mail et d'attendre que quelqu'un clique. Dans l'en-tête, c'est rare de voir une url et ça devrait rendre les gens méfiants. -- Si vous avez du temps Í perdre : https://scarpet42.gitlab.io
