J'utilise les sessions de PHP pour sécuriser mes pages. Ca marche
parfaitement bien. L'accès aux pages necessite une authentification au
préalable.
Par contre, les documents qui sont proposés aux membres depuis les
pages sécurisées par mes sessions ne sont pas sécurisés par PHP
puisqu'ils
résident sur le serveur et demeurent accessibles directement via
l'url.
Comment y remédier ?
J'ai bien pensé à la solution .htaccess...mais cela me fait gérer
deux
systèmes en parallele (c'est pas propre et on est obligé de se loguer
plusieurs fois (une pour les sessions, une pour le htaccess) quelqu'un
peut-il m'aider ?
Si jamais c'est pas clair, supposez que le document en question soit
une image qui ne doit etre visible que en mode sécurisé ( avec les
sessions idéalement). Il ne faut pas que cette image puisse etre
accessible via http://www.monsite.com/blabla/image.jpg )
J'utilise les sessions de PHP pour sécuriser mes pages.
Et pourquoi pas directement un .htaccess ?
Par contre, les documents qui sont proposés aux membres depuis les pages sécurisées par mes sessions ne sont pas sécurisés par PHP puisqu'ils résident sur le serveur et demeurent accessibles directement via l'url.
Mettre ces documents hors de la hiérarchie "web", et faire un script PHP qui vérifie l'autorisation d'accès, et renvoie le contenu du fichier :
<?php if (AccesAutorisé()) { header ("Content-Type: image/png"); readfile ("/home/images/xdka.jpg"); }
... Avec bien sûr toutes les vérifications d'usage pour s'assurer que le script ne donne accès qu'à certains fichiers.
Seul problème, certaines versions d'IE (voire même toutes ?) ont un bug, elles ignorent le "Content-Type" :-(
-- Le grand site de la philosophie animale : <http://perso.edulang.com/philo/>
On 10 May 2005 18:53:45 GMT, "Adrieno" <adrien.dain@gmail.com>:
J'utilise les sessions de PHP pour sécuriser mes pages.
Et pourquoi pas directement un .htaccess ?
Par contre, les documents qui sont proposés aux membres depuis les
pages sécurisées par mes sessions ne sont pas sécurisés par PHP
puisqu'ils
résident sur le serveur et demeurent accessibles directement via
l'url.
Mettre ces documents hors de la hiérarchie "web", et faire un script
PHP qui vérifie l'autorisation d'accès, et renvoie le contenu du
fichier :
<?php
if (AccesAutorisé())
{
header ("Content-Type: image/png");
readfile ("/home/images/xdka.jpg");
}
... Avec bien sûr toutes les vérifications d'usage pour s'assurer que
le script ne donne accès qu'à certains fichiers.
Seul problème, certaines versions d'IE (voire même toutes ?) ont un
bug, elles ignorent le "Content-Type" :-(
--
Le grand site de la philosophie animale : <http://perso.edulang.com/philo/>
J'utilise les sessions de PHP pour sécuriser mes pages.
Et pourquoi pas directement un .htaccess ?
Par contre, les documents qui sont proposés aux membres depuis les pages sécurisées par mes sessions ne sont pas sécurisés par PHP puisqu'ils résident sur le serveur et demeurent accessibles directement via l'url.
Mettre ces documents hors de la hiérarchie "web", et faire un script PHP qui vérifie l'autorisation d'accès, et renvoie le contenu du fichier :
<?php if (AccesAutorisé()) { header ("Content-Type: image/png"); readfile ("/home/images/xdka.jpg"); }
... Avec bien sûr toutes les vérifications d'usage pour s'assurer que le script ne donne accès qu'à certains fichiers.
Seul problème, certaines versions d'IE (voire même toutes ?) ont un bug, elles ignorent le "Content-Type" :-(
-- Le grand site de la philosophie animale : <http://perso.edulang.com/philo/>
Nicob
On Tue, 10 May 2005 20:19:19 +0000, Fabien LE LEZ wrote:
Seul problème, certaines versions d'IE (voire même toutes ?) ont un bug, elles ignorent le "Content-Type" :-(
"Ce n'est pas un bug, c'est une feature"
On appelle ça du "MIME Sniffing", et d'ailleurs Opera faisait exactement la même chose, justement pour émuler au mieux le comportement d'IE. Mais je viens de tester et ça a l'air OK (ie. différent d'IE) à présent.
Par contre, IE n'en fait toujours qu'à sa tête (WinXP SP2) : - s'il connaît le type MIME proposé, il analyse les données reçues afin de déterminer quel moteur utiliser pour le rendu (!) - s'il ne connaît pas le type MIME, il propose le téléchargement des données reçues (avec warning à l'utilisateur et tout le toutim)
Pour tester le comportement d'un browser (envoi de code HTML avec un type MIME "text/plain") :
http://nicob.net/cgi-bin/content-type.cgi
Nicob
On Tue, 10 May 2005 20:19:19 +0000, Fabien LE LEZ wrote:
Seul problème, certaines versions d'IE (voire même toutes ?) ont un
bug, elles ignorent le "Content-Type" :-(
"Ce n'est pas un bug, c'est une feature"
On appelle ça du "MIME Sniffing", et d'ailleurs Opera faisait exactement
la même chose, justement pour émuler au mieux le comportement d'IE. Mais
je viens de tester et ça a l'air OK (ie. différent d'IE) à présent.
Par contre, IE n'en fait toujours qu'à sa tête (WinXP SP2) :
- s'il connaît le type MIME proposé, il analyse les données reçues afin
de déterminer quel moteur utiliser pour le rendu (!)
- s'il ne connaît pas le type MIME, il propose le téléchargement des
données reçues (avec warning à l'utilisateur et tout le toutim)
Pour tester le comportement d'un browser (envoi de code HTML avec un type
MIME "text/plain") :
On Tue, 10 May 2005 20:19:19 +0000, Fabien LE LEZ wrote:
Seul problème, certaines versions d'IE (voire même toutes ?) ont un bug, elles ignorent le "Content-Type" :-(
"Ce n'est pas un bug, c'est une feature"
On appelle ça du "MIME Sniffing", et d'ailleurs Opera faisait exactement la même chose, justement pour émuler au mieux le comportement d'IE. Mais je viens de tester et ça a l'air OK (ie. différent d'IE) à présent.
Par contre, IE n'en fait toujours qu'à sa tête (WinXP SP2) : - s'il connaît le type MIME proposé, il analyse les données reçues afin de déterminer quel moteur utiliser pour le rendu (!) - s'il ne connaît pas le type MIME, il propose le téléchargement des données reçues (avec warning à l'utilisateur et tout le toutim)
Pour tester le comportement d'un browser (envoi de code HTML avec un type MIME "text/plain") :
http://nicob.net/cgi-bin/content-type.cgi
Nicob
Fabien LE LEZ
On 10 May 2005 21:34:33 GMT, Nicob :
Seul problème, certaines versions d'IE (voire même toutes ?) ont un bug, elles ignorent le "Content-Type" :-(
"Ce n'est pas un bug, c'est une feature"
On appelle ça un bug-by-feature (ou bug-by-design).
[...] Par contre, IE n'en fait toujours qu'à sa tête (WinXP SP2) : - s'il connaît le type MIME proposé, il analyse les données reçues afin de déterminer quel moteur utiliser pour le rendu (!) - s'il ne connaît pas le type MIME, il propose le téléchargement des données reçues (avec warning à l'utilisateur et tout le toutim) [...]
Y'a quelque chose qui a motivé ce comportement, à part la bêtise d'un gars haut placé chez MS ?
Attention : copie et fu2 sur fr.comp.infosystemes.www.navigateurs.
-- Le grand site de la philosophie animale : <http://perso.edulang.com/philo/>
On 10 May 2005 21:34:33 GMT, Nicob <nicob@I.hate.spammers.com>:
Seul problème, certaines versions d'IE (voire même toutes ?) ont un
bug, elles ignorent le "Content-Type" :-(
"Ce n'est pas un bug, c'est une feature"
On appelle ça un bug-by-feature (ou bug-by-design).
[...]
Par contre, IE n'en fait toujours qu'à sa tête (WinXP SP2) :
- s'il connaît le type MIME proposé, il analyse les données reçues afin
de déterminer quel moteur utiliser pour le rendu (!)
- s'il ne connaît pas le type MIME, il propose le téléchargement des
données reçues (avec warning à l'utilisateur et tout le toutim)
[...]
Y'a quelque chose qui a motivé ce comportement, à part la bêtise d'un
gars haut placé chez MS ?
Attention : copie et fu2 sur fr.comp.infosystemes.www.navigateurs.
--
Le grand site de la philosophie animale : <http://perso.edulang.com/philo/>
Seul problème, certaines versions d'IE (voire même toutes ?) ont un bug, elles ignorent le "Content-Type" :-(
"Ce n'est pas un bug, c'est une feature"
On appelle ça un bug-by-feature (ou bug-by-design).
[...] Par contre, IE n'en fait toujours qu'à sa tête (WinXP SP2) : - s'il connaît le type MIME proposé, il analyse les données reçues afin de déterminer quel moteur utiliser pour le rendu (!) - s'il ne connaît pas le type MIME, il propose le téléchargement des données reçues (avec warning à l'utilisateur et tout le toutim) [...]
Y'a quelque chose qui a motivé ce comportement, à part la bêtise d'un gars haut placé chez MS ?
Attention : copie et fu2 sur fr.comp.infosystemes.www.navigateurs.
-- Le grand site de la philosophie animale : <http://perso.edulang.com/philo/>
Adrieno
Pourquoi pas htaccess ? Bein parceque c'est pas vraiment user friendly et puis c'est destiné à un grand public. Les sessions sont plus adaptées.
En fait le fichier que je souhaite proteger est un fichier flash (swf).
supposons qu'il se trouve sur www.monsite.com/securise/appli.swf
Je veux que ce fichier ne soit accessible que par les gens inscrits sur le site( utilisation de sessions !?)
Dans l'état actuel des choses, www.monsite.com/securise/appli.swf est accessible et ne necessite aucune authentification alors que la page mere (celle qui appelle le appli.swf) est sécurisée
C'est un grosse grosse faille de sécurité qui ne peut etre ignorée.
SVP . C'est urgent. MERCI !!!
Pourquoi pas htaccess ?
Bein parceque c'est pas vraiment user friendly et puis c'est destiné
à un grand public. Les sessions sont plus adaptées.
En fait le fichier que je souhaite proteger est un fichier flash (swf).
supposons qu'il se trouve sur www.monsite.com/securise/appli.swf
Je veux que ce fichier ne soit accessible que par les gens inscrits sur
le site( utilisation de sessions !?)
Dans l'état actuel des choses, www.monsite.com/securise/appli.swf est
accessible et ne necessite aucune authentification alors que la page
mere (celle qui appelle le appli.swf) est sécurisée
C'est un grosse grosse faille de sécurité qui ne peut etre ignorée.
Pourquoi pas htaccess ? Bein parceque c'est pas vraiment user friendly et puis c'est destiné à un grand public. Les sessions sont plus adaptées.
En fait le fichier que je souhaite proteger est un fichier flash (swf).
supposons qu'il se trouve sur www.monsite.com/securise/appli.swf
Je veux que ce fichier ne soit accessible que par les gens inscrits sur le site( utilisation de sessions !?)
Dans l'état actuel des choses, www.monsite.com/securise/appli.swf est accessible et ne necessite aucune authentification alors que la page mere (celle qui appelle le appli.swf) est sécurisée
C'est un grosse grosse faille de sécurité qui ne peut etre ignorée.
SVP . C'est urgent. MERCI !!!
Julien
Adrieno wrote:
Pourquoi pas htaccess ? Bein parceque c'est pas vraiment user friendly et puis c'est destiné à un grand public. Les sessions sont plus adaptées.
En fait le fichier que je souhaite proteger est un fichier flash (swf).
supposons qu'il se trouve sur www.monsite.com/securise/appli.swf
Je veux que ce fichier ne soit accessible que par les gens inscrits sur le site( utilisation de sessions !?)
Dans l'état actuel des choses, www.monsite.com/securise/appli.swf est accessible et ne necessite aucune authentification alors que la page mere (celle qui appelle le appli.swf) est sécurisée
C'est un grosse grosse faille de sécurité qui ne peut etre ignorée.
1. tu mets tes fichiers swf dans un répertoire qui n'est pas dans ta racine web 2. tu fais un script php dont un argument est le nom de ton fichier (tu le fais passer comme tu veux ...) -> dans ce script tu verifies que l'utilisateur est bien enregitré -> si oui tu ouvres le fichier en admettant que tu aies placé le path complet de ton fichier dans $filename : header('Content-Type: application/x-shockwave-flash', true); header('Content-Length: ' . filesize($filename), true); readfile($filename); exit;
Et voila ... il faut quand même penser à la sécurité des répertoires (par exemple que ce soit pas possible de mettre ../../filename comme nom de fichier).
-- Julien
Adrieno wrote:
Pourquoi pas htaccess ?
Bein parceque c'est pas vraiment user friendly et puis c'est destiné
à un grand public. Les sessions sont plus adaptées.
En fait le fichier que je souhaite proteger est un fichier flash (swf).
supposons qu'il se trouve sur www.monsite.com/securise/appli.swf
Je veux que ce fichier ne soit accessible que par les gens inscrits sur
le site( utilisation de sessions !?)
Dans l'état actuel des choses, www.monsite.com/securise/appli.swf est
accessible et ne necessite aucune authentification alors que la page
mere (celle qui appelle le appli.swf) est sécurisée
C'est un grosse grosse faille de sécurité qui ne peut etre ignorée.
1. tu mets tes fichiers swf dans un répertoire qui n'est pas dans ta
racine web
2. tu fais un script php dont un argument est le nom de ton fichier (tu
le fais passer comme tu veux ...)
-> dans ce script tu verifies que l'utilisateur est bien enregitré
-> si oui tu ouvres le fichier
en admettant que tu aies placé le path complet de ton fichier dans
$filename :
header('Content-Type: application/x-shockwave-flash', true);
header('Content-Length: ' . filesize($filename), true);
readfile($filename);
exit;
Et voila ... il faut quand même penser à la sécurité des répertoires
(par exemple que ce soit pas possible de mettre ../../filename comme nom
de fichier).
Pourquoi pas htaccess ? Bein parceque c'est pas vraiment user friendly et puis c'est destiné à un grand public. Les sessions sont plus adaptées.
En fait le fichier que je souhaite proteger est un fichier flash (swf).
supposons qu'il se trouve sur www.monsite.com/securise/appli.swf
Je veux que ce fichier ne soit accessible que par les gens inscrits sur le site( utilisation de sessions !?)
Dans l'état actuel des choses, www.monsite.com/securise/appli.swf est accessible et ne necessite aucune authentification alors que la page mere (celle qui appelle le appli.swf) est sécurisée
C'est un grosse grosse faille de sécurité qui ne peut etre ignorée.
1. tu mets tes fichiers swf dans un répertoire qui n'est pas dans ta racine web 2. tu fais un script php dont un argument est le nom de ton fichier (tu le fais passer comme tu veux ...) -> dans ce script tu verifies que l'utilisateur est bien enregitré -> si oui tu ouvres le fichier en admettant que tu aies placé le path complet de ton fichier dans $filename : header('Content-Type: application/x-shockwave-flash', true); header('Content-Length: ' . filesize($filename), true); readfile($filename); exit;
Et voila ... il faut quand même penser à la sécurité des répertoires (par exemple que ce soit pas possible de mettre ../../filename comme nom de fichier).
-- Julien
Adrieno
Il n'y a pas plusieurs mais une seule appli swf à securiser. C'est le coeur du site.
Mais ok je vois ce que tu veux dire.
le probleme c'est que, in fine, si l'utilisateur final se connecte sur son espace securisé et edites la page contenant le fichier flash swf il voit :
Autrement dit, le chemin du swf est en clair. Rien n'empeche un utilisateur ensuite d'aller de copier le nom du swf et taper l'url www.monsite.com/secure/appli.swf
et hop ... il bypass toute la sécurité du site :)
Il n'y a pas plusieurs mais une seule appli swf à securiser. C'est le
coeur du site.
Mais ok je vois ce que tu veux dire.
le probleme c'est que, in fine, si l'utilisateur final se connecte sur
son espace securisé et edites la page contenant le fichier flash swf
il voit :
Autrement dit, le chemin du swf est en clair. Rien n'empeche un
utilisateur ensuite d'aller de copier le nom du swf et taper l'url
www.monsite.com/secure/appli.swf
Autrement dit, le chemin du swf est en clair. Rien n'empeche un utilisateur ensuite d'aller de copier le nom du swf et taper l'url www.monsite.com/secure/appli.swf
Qu'est ce qui empeche de remplacer ça par "/secure/download.php?name=appli.swf" ?
et hop ... il bypass toute la sécurité du site :)
Ben oui mais avec la méthode évoquée ça marche quand meme. En revanche je suggere de remplacer ça par
"/secure/download.php?file=1"
et d'avoir une table de correspondance dans le .php ou dans un fichier a coté entre l'index et le nom du fichier qui évidemment sera en dehors de la webroot. Ca évitera deja des catastrophes avec fopen() ou les ../ .
Le script download.php devra etre capable avec header() d'envoyer le bon Content-Type pour des fichier Flash. Ensuite il utilise readfile() et voila c'est marre. Y a des exemples sur http://www.php.net/manual/en/function.readfile.php
-- A: Yes.
Q: Are you sure?
A: Because it reverses the logical flow of conversation.
Qu'est ce qui empeche de remplacer ça par
"/secure/download.php?name=appli.swf" ?
et hop ... il bypass toute la sécurité du site :)
Ben oui mais avec la méthode évoquée ça marche quand meme. En revanche
je suggere de remplacer ça par
"/secure/download.php?file=1"
et d'avoir une table de correspondance dans le .php ou dans un fichier a
coté entre l'index et le nom du fichier qui évidemment sera en dehors de
la webroot. Ca évitera deja des catastrophes avec fopen() ou les ../ .
Le script download.php devra etre capable avec header() d'envoyer le bon
Content-Type pour des fichier Flash. Ensuite il utilise readfile() et
voila c'est marre. Y a des exemples sur
http://www.php.net/manual/en/function.readfile.php
--
A: Yes.
Q: Are you sure?
A: Because it reverses the logical flow of conversation.
Qu'est ce qui empeche de remplacer ça par "/secure/download.php?name=appli.swf" ?
et hop ... il bypass toute la sécurité du site :)
Ben oui mais avec la méthode évoquée ça marche quand meme. En revanche je suggere de remplacer ça par
"/secure/download.php?file=1"
et d'avoir une table de correspondance dans le .php ou dans un fichier a coté entre l'index et le nom du fichier qui évidemment sera en dehors de la webroot. Ca évitera deja des catastrophes avec fopen() ou les ../ .
Le script download.php devra etre capable avec header() d'envoyer le bon Content-Type pour des fichier Flash. Ensuite il utilise readfile() et voila c'est marre. Y a des exemples sur http://www.php.net/manual/en/function.readfile.php
-- A: Yes.
Q: Are you sure?
A: Because it reverses the logical flow of conversation.
Q: Why is top posting annoying in email?
Fabien LE LEZ
On 11 May 2005 15:55:57 GMT, "Adrieno" :
<embed src="/secure/appli.swf" quality=high
Erreur ici, il faut écrire
<embed src="acces_flash.php?nom_fichier=appli.swf" quality=high -- Le grand site de la philosophie animale : <http://perso.edulang.com/philo/>
On 11 May 2005 15:55:57 GMT, "Adrieno" <adrien.dain@gmail.com>:
<embed src="/secure/appli.swf" quality=high
Erreur ici, il faut écrire
<embed src="acces_flash.php?nom_fichier=appli.swf" quality=high
--
Le grand site de la philosophie animale : <http://perso.edulang.com/philo/>
<embed src="acces_flash.php?nom_fichier=appli.swf" quality=high -- Le grand site de la philosophie animale : <http://perso.edulang.com/philo/>
Julien
Adrieno wrote:
Il n'y a pas plusieurs mais une seule appli swf à securiser. C'est le coeur du site.
[snip]
Autrement dit, le chemin du swf est en clair. Rien n'empeche un utilisateur ensuite d'aller de copier le nom du swf et taper l'url www.monsite.com/secure/appli.swf
et hop ... il bypass toute la sécurité du site :)
... et donc tu n'as pas lu ma réponse ... ou alors pas comprise. Je te parle de faire une page dans ton site qui te permette d'afficher l'application SANS QU'ELLE SOIT dans le webroot de ton serveur http, donc impossible pour un visiteur d'y accéder directement (il est obligé de passer par la page, qui elle vérifie l'identification de la personne).
-- Julien
Adrieno wrote:
Il n'y a pas plusieurs mais une seule appli swf à securiser. C'est le
coeur du site.
[snip]
Autrement dit, le chemin du swf est en clair. Rien n'empeche un
utilisateur ensuite d'aller de copier le nom du swf et taper l'url
www.monsite.com/secure/appli.swf
et hop ... il bypass toute la sécurité du site :)
... et donc tu n'as pas lu ma réponse ... ou alors pas comprise.
Je te parle de faire une page dans ton site qui te permette d'afficher
l'application SANS QU'ELLE SOIT dans le webroot de ton serveur http,
donc impossible pour un visiteur d'y accéder directement (il est obligé
de passer par la page, qui elle vérifie l'identification de la personne).
Il n'y a pas plusieurs mais une seule appli swf à securiser. C'est le coeur du site.
[snip]
Autrement dit, le chemin du swf est en clair. Rien n'empeche un utilisateur ensuite d'aller de copier le nom du swf et taper l'url www.monsite.com/secure/appli.swf
et hop ... il bypass toute la sécurité du site :)
... et donc tu n'as pas lu ma réponse ... ou alors pas comprise. Je te parle de faire une page dans ton site qui te permette d'afficher l'application SANS QU'ELLE SOIT dans le webroot de ton serveur http, donc impossible pour un visiteur d'y accéder directement (il est obligé de passer par la page, qui elle vérifie l'identification de la personne).
Tout à fait. D'ailleurs ce genre de thread montre (ce n'est pas limité à ce posteur) que beaucoup (je pourrais dire "la plupart") de développeurs d'application Web n'ont *AUCUNE* idée du fonctionnement du modèle HTTP, des échanges effectués entre un navigateur et un serveur, de ce qui tourne sur le poste client, de ce qui est traité par le serveur, de ce qui est de confiance et susceptible d'etre altéré, etc... Quand on commence a ajouter des SWF ou du Java, c'est encore pire.
Un exemple: Je pense que tous les professionnels de la sécurité ici on deja rencontré ici des applications ASP ou PHP qui quand l'utilisateur n'est pas authentifé, renvoient un redirect en Javascript au début de la page et continue a exécuter le code ... J'ai croisé ça deux fois en quelques semaines, c'est fou.
Un autre exemple qu'on a m'a rapporté : le servlet qui ne fonctionne que si Tomcat est lancé depuis un écran X (sisi): pour obtenir la résolution de l'écran du navigateur, il utilise la classe Swing java.awt.GraphicsConfiguration ...
C'est fou qu'on mette des gens qui n'ont rien compris à HTTP au développement d'applis qui servent des données confidentielles, y compris dans plus grosses SSII françaises. Même le pire électricien de quartier comprend a peu près qu'il faut que le circuit électrique soit continu pour que l'ampoule s'allume , même le pire mécano a une vague idée du fonctionnement d'un moteur.
A coté de ça, il y a une minorité de professionnels qui font du travail très correct.
Que faire ?
-- A: Yes.
Q: Are you sure?
A: Because it reverses the logical flow of conversation.
Q: Why is top posting annoying in email?
Fabien LE LEZ <gramster@gramster.com> wrote:
On 11 May 2005 15:55:57 GMT, "Adrieno" <adrien.dain@gmail.com>:
Tout à fait. D'ailleurs ce genre de thread montre (ce n'est pas limité à
ce posteur) que beaucoup (je pourrais dire "la plupart") de développeurs
d'application Web n'ont *AUCUNE* idée du fonctionnement du modèle HTTP,
des échanges effectués entre un navigateur et un serveur, de ce qui
tourne sur le poste client, de ce qui est traité par le serveur, de ce
qui est de confiance et susceptible d'etre altéré, etc... Quand on
commence a ajouter des SWF ou du Java, c'est encore pire.
Un exemple: Je pense que tous les professionnels de la sécurité ici on
deja rencontré ici des applications ASP ou PHP qui quand l'utilisateur
n'est pas authentifé, renvoient un redirect en Javascript au début de la
page et continue a exécuter le code ... J'ai croisé ça deux fois en
quelques semaines, c'est fou.
Un autre exemple qu'on a m'a rapporté : le servlet qui ne fonctionne que
si Tomcat est lancé depuis un écran X (sisi): pour obtenir la résolution de
l'écran du navigateur, il utilise la classe Swing
java.awt.GraphicsConfiguration ...
C'est fou qu'on mette des gens qui n'ont rien compris à HTTP au
développement d'applis qui servent des données confidentielles, y
compris dans plus grosses SSII françaises. Même le pire électricien de
quartier comprend a peu près qu'il faut que le circuit électrique soit
continu pour que l'ampoule s'allume , même le pire mécano a une vague
idée du fonctionnement d'un moteur.
A coté de ça, il y a une minorité de professionnels qui font du travail
très correct.
Que faire ?
--
A: Yes.
Q: Are you sure?
A: Because it reverses the logical flow of conversation.
Tout à fait. D'ailleurs ce genre de thread montre (ce n'est pas limité à ce posteur) que beaucoup (je pourrais dire "la plupart") de développeurs d'application Web n'ont *AUCUNE* idée du fonctionnement du modèle HTTP, des échanges effectués entre un navigateur et un serveur, de ce qui tourne sur le poste client, de ce qui est traité par le serveur, de ce qui est de confiance et susceptible d'etre altéré, etc... Quand on commence a ajouter des SWF ou du Java, c'est encore pire.
Un exemple: Je pense que tous les professionnels de la sécurité ici on deja rencontré ici des applications ASP ou PHP qui quand l'utilisateur n'est pas authentifé, renvoient un redirect en Javascript au début de la page et continue a exécuter le code ... J'ai croisé ça deux fois en quelques semaines, c'est fou.
Un autre exemple qu'on a m'a rapporté : le servlet qui ne fonctionne que si Tomcat est lancé depuis un écran X (sisi): pour obtenir la résolution de l'écran du navigateur, il utilise la classe Swing java.awt.GraphicsConfiguration ...
C'est fou qu'on mette des gens qui n'ont rien compris à HTTP au développement d'applis qui servent des données confidentielles, y compris dans plus grosses SSII françaises. Même le pire électricien de quartier comprend a peu près qu'il faut que le circuit électrique soit continu pour que l'ampoule s'allume , même le pire mécano a une vague idée du fonctionnement d'un moteur.
A coté de ça, il y a une minorité de professionnels qui font du travail très correct.
Que faire ?
-- A: Yes.
Q: Are you sure?
A: Because it reverses the logical flow of conversation.
