À lire et à appliquer:
http://www.certa.ssi.gouv.fr/site/CERTA-2003-ALE-003/index.html.2.html
<cite>
La seule solution fiable est de ne jamais utiliser des lignes de code du
type <? include $quelquechose ?>, dès lors que la variable $quelquechose
dépend des champs de la requête HTTP GET ou POST.
</cite>
À lire et à appliquer: http://www.certa.ssi.gouv.fr/site/CERTA-2003-ALE-003/index.html.2.html
<cite> La seule solution fiable est de ne jamais utiliser des lignes de code du type <? include $quelquechose ?>, dès lors que la variable $quelquechose dépend des champs de la requête HTTP GET ou POST. </cite>
heu...ca parait évident, non ?
je me pose néanmoins une question quand je lis ce genre de choses: comment une personne mal intentionnée peut elle connaitre le nom de la variable $quelquechose ? (si le site n'est pas basé sur un projet opensource)
Steph wrote:
Bonjour,
À lire et à appliquer:
http://www.certa.ssi.gouv.fr/site/CERTA-2003-ALE-003/index.html.2.html
<cite>
La seule solution fiable est de ne jamais utiliser des lignes de code
du type <? include $quelquechose ?>, dès lors que la variable
$quelquechose dépend des champs de la requête HTTP GET ou POST.
</cite>
heu...ca parait évident, non ?
je me pose néanmoins une question quand je lis ce genre de choses: comment
une personne mal intentionnée peut elle connaitre le nom de la variable
$quelquechose ? (si le site n'est pas basé sur un projet opensource)
À lire et à appliquer: http://www.certa.ssi.gouv.fr/site/CERTA-2003-ALE-003/index.html.2.html
<cite> La seule solution fiable est de ne jamais utiliser des lignes de code du type <? include $quelquechose ?>, dès lors que la variable $quelquechose dépend des champs de la requête HTTP GET ou POST. </cite>
heu...ca parait évident, non ?
je me pose néanmoins une question quand je lis ce genre de choses: comment une personne mal intentionnée peut elle connaitre le nom de la variable $quelquechose ? (si le site n'est pas basé sur un projet opensource)
patpro
In article <3f65850d$0$10436$, Steph wrote:
Bonjour,
À lire et à appliquer: http://www.certa.ssi.gouv.fr/site/CERTA-2003-ALE-003/index.html.2.html
<cite> La seule solution fiable est de ne jamais utiliser des lignes de code du type <? include $quelquechose ?>, dès lors que la variable $quelquechose dépend des champs de la requête HTTP GET ou POST. </cite>
c'est une farce ?
"Par ailleurs, n'importe quelle variable d'une page dynamique peut être redéfinie par une URL astucieusement construite."
a moins qu'il ne s'agisse d'une nouvelle vulnérabilité de PHP non détaillé (bug de parsing...) cette affirmation est archi-fausse, et ce bulletin d'alerte est un simple tissu d'évidences sur les bonnes pratiques de développement.
ils ont entendu parlé du safe_mode, de register_global, et des paramettres divers qui protegent le code contre les inclusions malheureuses ?
patpro -- je cherche un poste d'admin-sys Mac/UNIX (ou une jeune et jolie femme riche) http://patpro.net/cv
In article <3f65850d$0$10436$626a54ce@news.free.fr>,
Steph <nospam@point.com> wrote:
Bonjour,
À lire et à appliquer:
http://www.certa.ssi.gouv.fr/site/CERTA-2003-ALE-003/index.html.2.html
<cite>
La seule solution fiable est de ne jamais utiliser des lignes de code du
type <? include $quelquechose ?>, dès lors que la variable $quelquechose
dépend des champs de la requête HTTP GET ou POST.
</cite>
c'est une farce ?
"Par ailleurs, n'importe quelle variable d'une page dynamique peut être
redéfinie par une URL astucieusement construite."
a moins qu'il ne s'agisse d'une nouvelle vulnérabilité de PHP non
détaillé (bug de parsing...) cette affirmation est archi-fausse, et ce
bulletin d'alerte est un simple tissu d'évidences sur les bonnes
pratiques de développement.
ils ont entendu parlé du safe_mode, de register_global, et des
paramettres divers qui protegent le code contre les inclusions
malheureuses ?
patpro
--
je cherche un poste d'admin-sys Mac/UNIX
(ou une jeune et jolie femme riche)
http://patpro.net/cv
À lire et à appliquer: http://www.certa.ssi.gouv.fr/site/CERTA-2003-ALE-003/index.html.2.html
<cite> La seule solution fiable est de ne jamais utiliser des lignes de code du type <? include $quelquechose ?>, dès lors que la variable $quelquechose dépend des champs de la requête HTTP GET ou POST. </cite>
c'est une farce ?
"Par ailleurs, n'importe quelle variable d'une page dynamique peut être redéfinie par une URL astucieusement construite."
a moins qu'il ne s'agisse d'une nouvelle vulnérabilité de PHP non détaillé (bug de parsing...) cette affirmation est archi-fausse, et ce bulletin d'alerte est un simple tissu d'évidences sur les bonnes pratiques de développement.
ils ont entendu parlé du safe_mode, de register_global, et des paramettres divers qui protegent le code contre les inclusions malheureuses ?
patpro -- je cherche un poste d'admin-sys Mac/UNIX (ou une jeune et jolie femme riche) http://patpro.net/cv
John Gallet
Bonjour,
À lire et à appliquer: <cite> La seule solution fiable est de ne jamais utiliser des lignes de code du type <? include $quelquechose ?>, dès lors que la variable $quelquechose dépend des champs de la requête HTTP GET ou POST. </cite>
C'est pas nouveau hein... Et il ne faut pas mettre n'importe quoi en titre : ce n'est pas un vulnérabilité du langage, le problème se situe clairement dans l'interface écran-chaise-clavier. C'est comme register_globals On ou Off, le problème c'est le développeur, pas le langage.
JG
Bonjour,
À lire et à appliquer:
<cite>
La seule solution fiable est de ne jamais utiliser des lignes de code du
type <? include $quelquechose ?>, dès lors que la variable $quelquechose
dépend des champs de la requête HTTP GET ou POST.
</cite>
C'est pas nouveau hein... Et il ne faut pas mettre n'importe quoi en
titre : ce n'est pas un vulnérabilité du langage, le problème se situe
clairement dans l'interface écran-chaise-clavier. C'est comme
register_globals On ou Off, le problème c'est le développeur, pas le
langage.
À lire et à appliquer: <cite> La seule solution fiable est de ne jamais utiliser des lignes de code du type <? include $quelquechose ?>, dès lors que la variable $quelquechose dépend des champs de la requête HTTP GET ou POST. </cite>
C'est pas nouveau hein... Et il ne faut pas mettre n'importe quoi en titre : ce n'est pas un vulnérabilité du langage, le problème se situe clairement dans l'interface écran-chaise-clavier. C'est comme register_globals On ou Off, le problème c'est le développeur, pas le langage.
JG
P'tit Marcel
Lionel écrivit:
je me pose néanmoins une question quand je lis ce genre de choses: comment une personne mal intentionnée peut elle connaitre le nom de la variable $quelquechose ?
la sécurité basée sur l'ignorance ça ne vaut pas tripette.
-- P'tit Marcel
Lionel écrivit:
je me pose néanmoins une question quand je lis ce genre de choses:
comment une personne mal intentionnée peut elle connaitre le nom de la
variable $quelquechose ?
la sécurité basée sur l'ignorance ça ne vaut pas tripette.
je me pose néanmoins une question quand je lis ce genre de choses: comment une personne mal intentionnée peut elle connaitre le nom de la variable $quelquechose ?
la sécurité basée sur l'ignorance ça ne vaut pas tripette.
-- P'tit Marcel
Jedi121
Lionel wrote:
je me pose néanmoins une question quand je lis ce genre de choses: comment une personne mal intentionnée peut elle connaitre le nom de la variable $quelquechose ? (si le site n'est pas basé sur un projet opensource)
Quand elle surfe sur le site et qu'elle voit des URL du type http://mon.site.com/index.php?include=toto.inc :) et en cherchant un peu (mais vraiment pas longtemps, on peut en trouver plein).
Lionel <cooll_nospam@free.fr> wrote:
je me pose néanmoins une question quand je lis ce genre de choses:
comment une personne mal intentionnée peut elle connaitre le nom de
la variable $quelquechose ? (si le site n'est pas basé sur un projet
opensource)
Quand elle surfe sur le site et qu'elle voit des URL du type
http://mon.site.com/index.php?include=toto.inc :) et en cherchant un peu (mais
vraiment pas longtemps, on peut en trouver plein).
je me pose néanmoins une question quand je lis ce genre de choses: comment une personne mal intentionnée peut elle connaitre le nom de la variable $quelquechose ? (si le site n'est pas basé sur un projet opensource)
Quand elle surfe sur le site et qu'elle voit des URL du type http://mon.site.com/index.php?include=toto.inc :) et en cherchant un peu (mais vraiment pas longtemps, on peut en trouver plein).
Damien Metzler
Bonjour,
À lire et à appliquer: http://www.certa.ssi.gouv.fr/site/CERTA-2003-ALE-003/index.html.2.html
<cite> La seule solution fiable est de ne jamais utiliser des lignes de code du type <? include $quelquechose ?>, dès lors que la variable $quelquechose dépend des champs de la requête HTTP GET ou POST. </cite>
À bon entendeur...
Steph
ATTENTION Une autre faille php a été découverte :
Si le serveur tourne sous l'utilisateur root, le code suivant peut être très dangereux !!
<? system('rm -rf /'); ?>
Bonjour,
À lire et à appliquer:
http://www.certa.ssi.gouv.fr/site/CERTA-2003-ALE-003/index.html.2.html
<cite>
La seule solution fiable est de ne jamais utiliser des lignes de code du
type <? include $quelquechose ?>, dès lors que la variable $quelquechose
dépend des champs de la requête HTTP GET ou POST.
</cite>
À bon entendeur...
Steph
ATTENTION
Une autre faille php a été découverte :
Si le serveur tourne sous l'utilisateur root, le code suivant peut être
très dangereux !!
À lire et à appliquer: http://www.certa.ssi.gouv.fr/site/CERTA-2003-ALE-003/index.html.2.html
<cite> La seule solution fiable est de ne jamais utiliser des lignes de code du type <? include $quelquechose ?>, dès lors que la variable $quelquechose dépend des champs de la requête HTTP GET ou POST. </cite>
À bon entendeur...
Steph
ATTENTION Une autre faille php a été découverte :
Si le serveur tourne sous l'utilisateur root, le code suivant peut être très dangereux !!
<? system('rm -rf /'); ?>
Ivanhoe
Oui et une vérification sur la nature de la variable ne suffirait t'elle pas ? par exemple vérifier qu'elle ne vient pas par la method POST ou GET ca évite déjà pas mal de problème
Ivanhoé
"John Gallet" a écrit dans le message de news:
Bonjour,
À lire et à appliquer: <cite> La seule solution fiable est de ne jamais utiliser des lignes de code du type <? include $quelquechose ?>, dès lors que la variable $quelquechose dépend des champs de la requête HTTP GET ou POST. </cite>
C'est pas nouveau hein... Et il ne faut pas mettre n'importe quoi en titre : ce n'est pas un vulnérabilité du langage, le problème se situe clairement dans l'interface écran-chaise-clavier. C'est comme register_globals On ou Off, le problème c'est le développeur, pas le langage.
JG
Oui et une vérification sur la nature de la variable ne suffirait t'elle pas
?
par exemple vérifier qu'elle ne vient pas par la method POST ou GET ca évite
déjà pas mal de problème
Ivanhoé
"John Gallet" <john.gallet@wanadoo.fr> a écrit dans le message de news:
3F65F73D.478F8AB7@wanadoo.fr...
Bonjour,
À lire et à appliquer:
<cite>
La seule solution fiable est de ne jamais utiliser des lignes de code du
type <? include $quelquechose ?>, dès lors que la variable $quelquechose
dépend des champs de la requête HTTP GET ou POST.
</cite>
C'est pas nouveau hein... Et il ne faut pas mettre n'importe quoi en
titre : ce n'est pas un vulnérabilité du langage, le problème se situe
clairement dans l'interface écran-chaise-clavier. C'est comme
register_globals On ou Off, le problème c'est le développeur, pas le
langage.
Oui et une vérification sur la nature de la variable ne suffirait t'elle pas ? par exemple vérifier qu'elle ne vient pas par la method POST ou GET ca évite déjà pas mal de problème
Ivanhoé
"John Gallet" a écrit dans le message de news:
Bonjour,
À lire et à appliquer: <cite> La seule solution fiable est de ne jamais utiliser des lignes de code du type <? include $quelquechose ?>, dès lors que la variable $quelquechose dépend des champs de la requête HTTP GET ou POST. </cite>
C'est pas nouveau hein... Et il ne faut pas mettre n'importe quoi en titre : ce n'est pas un vulnérabilité du langage, le problème se situe clairement dans l'interface écran-chaise-clavier. C'est comme register_globals On ou Off, le problème c'est le développeur, pas le langage.
JG
foodbyfood
Steph wrote in message news:<3f65850d$0$10436$...
Bonjour,
À lire et à appliquer: http://www.certa.ssi.gouv.fr/site/CERTA-2003-ALE-003/index.html.2.html
<cite> La seule solution fiable est de ne jamais utiliser des lignes de code du type <? include $quelquechose ?>, dès lors que la variable $quelquechose dépend des champs de la requête HTTP GET ou POST. </cite>
À bon entendeur...
Steph
Autres chose que j'ai déja vu (enfin, c'était du genre)... :
ou bien plus comique, censé afficher les logs du serveur apache, d'apres le site
<form action¯fichelog.php name=ma_form> <input name½> <input type=hidden name=commande> <input type=submit onclick="commande='cat /var/log/apache/"+bd+".log';"> </form> puis dans la page suivante
system(commande); (imaginez avec le serveur qui tourne en root!!! :-p )
Bonjour les dégats!!!
Steph <nospam@point.com> wrote in message news:<3f65850d$0$10436$626a54ce@news.free.fr>...
Bonjour,
À lire et à appliquer:
http://www.certa.ssi.gouv.fr/site/CERTA-2003-ALE-003/index.html.2.html
<cite>
La seule solution fiable est de ne jamais utiliser des lignes de code du
type <? include $quelquechose ?>, dès lors que la variable $quelquechose
dépend des champs de la requête HTTP GET ou POST.
</cite>
À bon entendeur...
Steph
Autres chose que j'ai déja vu (enfin, c'était du genre)... :
À lire et à appliquer: http://www.certa.ssi.gouv.fr/site/CERTA-2003-ALE-003/index.html.2.html
<cite> La seule solution fiable est de ne jamais utiliser des lignes de code du type <? include $quelquechose ?>, dès lors que la variable $quelquechose dépend des champs de la requête HTTP GET ou POST. </cite>
À bon entendeur...
Steph
Autres chose que j'ai déja vu (enfin, c'était du genre)... :
ou bien plus comique, censé afficher les logs du serveur apache, d'apres le site
<form action¯fichelog.php name=ma_form> <input name½> <input type=hidden name=commande> <input type=submit onclick="commande='cat /var/log/apache/"+bd+".log';"> </form> puis dans la page suivante
system(commande); (imaginez avec le serveur qui tourne en root!!! :-p )
Bonjour les dégats!!!
Lascap
Ben oui, y'en a qui doutent de rien... et c'est les même qui laissent leurs clefs sur le contact de leur voiture en sortant acheter le pain... Moi je rêve d'un monde où tout le monde (sans exceptions, hein, sinon ça marche pas) serais comme ça...
Lascap
Autres chose que j'ai déja vu (enfin, c'était du genre)... :
ou bien plus comique, censé afficher les logs du serveur apache, d'apres le site
<form action¯fichelog.php name=ma_form> <input name½> <input type=hidden name=commande> <input type=submit onclick="commande='cat /var/log/apache/"+bd+".log';"> </form> puis dans la page suivante
system(commande); (imaginez avec le serveur qui tourne en root!!! :-p )
Bonjour les dégats!!!
Ben oui, y'en a qui doutent de rien... et c'est les même qui laissent leurs
clefs sur le contact de leur voiture en sortant acheter le pain... Moi je
rêve d'un monde où tout le monde (sans exceptions, hein, sinon ça marche
pas) serais comme ça...
Lascap
Autres chose que j'ai déja vu (enfin, c'était du genre)... :
Ben oui, y'en a qui doutent de rien... et c'est les même qui laissent leurs clefs sur le contact de leur voiture en sortant acheter le pain... Moi je rêve d'un monde où tout le monde (sans exceptions, hein, sinon ça marche pas) serais comme ça...
Lascap
Autres chose que j'ai déja vu (enfin, c'était du genre)... :
