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 )
C'est très simple : s'assurer que les gens qu'on emploie (salariés, sous-traitants...) sont compétents, et laisser les guignols à la concurrence.
-- Le grand site de la philosophie animale : <http://perso.edulang.com/philo/>
Eric Razny
Le Wed, 11 May 2005 19:17:47 +0000, Fabien LE LEZ a écrit :
Que faire ?
C'est très simple : s'assurer que les gens qu'on emploie (salariés, sous-traitants...) sont compétents, et laisser les guignols à la concurrence.
Le problème dans le domaine de la sécurité c'est que sauf exception les gens qui s'adressent à un sous-traitant pour la réalisation n'ont pas les compétances pour juger de la qualification du sous traitant.
Résultat des courses c'est souvent ceux qui ont les "meilleurs" commerciaux qui récupèrent le boulot. J'ai déjà croisé des gus dans des grosses structures à qui je ne confirais même pas le blog de ma nièce et qui ont en charge des pans entier du SI de certaines boites :-(
Ca ne veux pas dire que tous sont nazes, loin de la mais qu'il me parrait quasiment impossible pour un profane d'identifier un professionnel sérieux. Pire il suffit qu'un gus balance des conneries crédibles et effrayantes (FUD) pour passer pour le sauveur.
<provoc> et ce n'est pas une quelconque accréditation gouvernementale - qui ne ferait que disqualifier des petits compétants (ou non) qui ont peu de moyens - qui changerait grand chose.</provoc>
Donc as tu un moyen de mettre en oeuvre ton "c'est très simple"?
Eric
Le Wed, 11 May 2005 19:17:47 +0000, Fabien LE LEZ a écrit :
Que faire ?
C'est très simple : s'assurer que les gens qu'on emploie (salariés,
sous-traitants...) sont compétents, et laisser les guignols à la
concurrence.
Le problème dans le domaine de la sécurité c'est que sauf exception les
gens qui s'adressent à un sous-traitant pour la réalisation n'ont pas
les compétances pour juger de la qualification du sous traitant.
Résultat des courses c'est souvent ceux qui ont les "meilleurs"
commerciaux qui récupèrent le boulot. J'ai déjà croisé des gus dans
des grosses structures à qui je ne confirais même pas le blog de ma
nièce et qui ont en charge des pans entier du SI de certaines boites :-(
Ca ne veux pas dire que tous sont nazes, loin de la mais qu'il me parrait
quasiment impossible pour un profane d'identifier un professionnel
sérieux. Pire il suffit qu'un gus balance des conneries crédibles et
effrayantes (FUD) pour passer pour le sauveur.
<provoc> et ce n'est pas une quelconque accréditation gouvernementale
- qui ne ferait que disqualifier des petits compétants (ou non) qui ont
peu de moyens - qui changerait grand chose.</provoc>
Donc as tu un moyen de mettre en oeuvre ton "c'est très simple"?
Le Wed, 11 May 2005 19:17:47 +0000, Fabien LE LEZ a écrit :
Que faire ?
C'est très simple : s'assurer que les gens qu'on emploie (salariés, sous-traitants...) sont compétents, et laisser les guignols à la concurrence.
Le problème dans le domaine de la sécurité c'est que sauf exception les gens qui s'adressent à un sous-traitant pour la réalisation n'ont pas les compétances pour juger de la qualification du sous traitant.
Résultat des courses c'est souvent ceux qui ont les "meilleurs" commerciaux qui récupèrent le boulot. J'ai déjà croisé des gus dans des grosses structures à qui je ne confirais même pas le blog de ma nièce et qui ont en charge des pans entier du SI de certaines boites :-(
Ca ne veux pas dire que tous sont nazes, loin de la mais qu'il me parrait quasiment impossible pour un profane d'identifier un professionnel sérieux. Pire il suffit qu'un gus balance des conneries crédibles et effrayantes (FUD) pour passer pour le sauveur.
<provoc> et ce n'est pas une quelconque accréditation gouvernementale - qui ne ferait que disqualifier des petits compétants (ou non) qui ont peu de moyens - qui changerait grand chose.</provoc>
Donc as tu un moyen de mettre en oeuvre ton "c'est très simple"?
Eric
Nicob
On Wed, 11 May 2005 19:17:47 +0000, Fabien LE LEZ wrote:
C'est très simple : s'assurer que les gens qu'on emploie (salariés, sous-traitants...) sont compétents, et laisser les guignols à la concurrence.
Pas d'accord. Le problème est d'abord de faire comprendre aux décideurs que maintenant que leur "coeur de métier" est accessible via le super Extranet de la mort qui tue, il serait temps d'arrêter de faire des sites Web comme d'autres font du jardinage, et de consacrer un peu d'argent à la sécurité de la chose.
Ceux qui ont compris l'importance de la chose et qui du coup appliquent des recettes de bon sens (intégration de la sécurité au projet dès la phase de conception, ajout de l'aspect sécurité aux obligations devant être remplies lors de la phase de recette, documentation exhaustive, process de gestion du changement, rationalisation du code par l'utilisation de bibliothèques "sécurisées", audit intrusif *avant* la mise en prod, ...) obtiennent rapidement des applications extrêmement robustes.
Euh ... je viens de me relire, je parle comme un consultant ;-)
Ce que je veux dire, c'est que rejoint totalement Alain Thivillon sur son dernier point. Dans la très grande majorité des cas, le niveau de sécurité est ridiculement faible, même si les données à protéger sont très très sensibles / secrètes / coûteuses / ... Mais il y a quelques sites "imprenables". Et malheureusement, je ne constate aucune corrélation entre la criticité des données et le niveau de sécurité :-(
Nicob
On Wed, 11 May 2005 19:17:47 +0000, Fabien LE LEZ wrote:
C'est très simple : s'assurer que les gens qu'on emploie (salariés,
sous-traitants...) sont compétents, et laisser les guignols à la
concurrence.
Pas d'accord. Le problème est d'abord de faire comprendre aux décideurs
que maintenant que leur "coeur de métier" est accessible via le
super Extranet de la mort qui tue, il serait temps d'arrêter de faire des
sites Web comme d'autres font du jardinage, et de consacrer un peu
d'argent à la sécurité de la chose.
Ceux qui ont compris l'importance de la chose et qui du coup appliquent
des recettes de bon sens (intégration de la sécurité au projet dès la
phase de conception, ajout de l'aspect sécurité aux obligations devant
être remplies lors de la phase de recette, documentation exhaustive,
process de gestion du changement, rationalisation du code par
l'utilisation de bibliothèques "sécurisées", audit intrusif *avant* la
mise en prod, ...) obtiennent rapidement des applications extrêmement
robustes.
Euh ... je viens de me relire, je parle comme un consultant ;-)
Ce que je veux dire, c'est que rejoint totalement Alain Thivillon sur son
dernier point. Dans la très grande majorité des cas, le niveau de
sécurité est ridiculement faible, même si les données à protéger
sont très très sensibles / secrètes / coûteuses / ... Mais il y a
quelques sites "imprenables". Et malheureusement, je ne constate aucune
corrélation entre la criticité des données et le niveau de sécurité :-(
On Wed, 11 May 2005 19:17:47 +0000, Fabien LE LEZ wrote:
C'est très simple : s'assurer que les gens qu'on emploie (salariés, sous-traitants...) sont compétents, et laisser les guignols à la concurrence.
Pas d'accord. Le problème est d'abord de faire comprendre aux décideurs que maintenant que leur "coeur de métier" est accessible via le super Extranet de la mort qui tue, il serait temps d'arrêter de faire des sites Web comme d'autres font du jardinage, et de consacrer un peu d'argent à la sécurité de la chose.
Ceux qui ont compris l'importance de la chose et qui du coup appliquent des recettes de bon sens (intégration de la sécurité au projet dès la phase de conception, ajout de l'aspect sécurité aux obligations devant être remplies lors de la phase de recette, documentation exhaustive, process de gestion du changement, rationalisation du code par l'utilisation de bibliothèques "sécurisées", audit intrusif *avant* la mise en prod, ...) obtiennent rapidement des applications extrêmement robustes.
Euh ... je viens de me relire, je parle comme un consultant ;-)
Ce que je veux dire, c'est que rejoint totalement Alain Thivillon sur son dernier point. Dans la très grande majorité des cas, le niveau de sécurité est ridiculement faible, même si les données à protéger sont très très sensibles / secrètes / coûteuses / ... Mais il y a quelques sites "imprenables". Et malheureusement, je ne constate aucune corrélation entre la criticité des données et le niveau de sécurité :-(
Nicob
Nicob
On Wed, 11 May 2005 20:54:54 +0000, Eric Razny wrote:
Ca ne veux pas dire que tous sont nazes, loin de la mais qu'il me parrait quasiment impossible pour un profane d'identifier un professionnel sérieux.
Auquel cas, il faut sous-traiter aussi la vérification de la solidité du produit livré. Mais on retombe dans le problème du choix du sous-traitant B (boîte de sécu) qui évaluera le travail du sous-traitant A (développement Web).
D'ailleurs, c'est quand même marrant que seules quelques rares entités aient compris que pour pourvoir disposer de très fortes compétences en sécurité, il est mieux d'intégrer des killers que de sous-traiter à foison. Bon, OK, il faut déjà avoir une certaine surface financière pour que la question se pose, mais j'aime vraiment bien l'idée de l'équipe interne de consulting avancé, formation et R&D.
Nicob
On Wed, 11 May 2005 20:54:54 +0000, Eric Razny wrote:
Ca ne veux pas dire que tous sont nazes, loin de la mais qu'il me
parrait quasiment impossible pour un profane d'identifier un
professionnel sérieux.
Auquel cas, il faut sous-traiter aussi la vérification de la solidité du
produit livré. Mais on retombe dans le problème du choix du
sous-traitant B (boîte de sécu) qui évaluera le travail du
sous-traitant A (développement Web).
D'ailleurs, c'est quand même marrant que seules quelques rares entités
aient compris que pour pourvoir disposer de très fortes compétences en
sécurité, il est mieux d'intégrer des killers que de sous-traiter à
foison. Bon, OK, il faut déjà avoir une certaine surface financière pour
que la question se pose, mais j'aime vraiment bien l'idée de l'équipe
interne de consulting avancé, formation et R&D.
On Wed, 11 May 2005 20:54:54 +0000, Eric Razny wrote:
Ca ne veux pas dire que tous sont nazes, loin de la mais qu'il me parrait quasiment impossible pour un profane d'identifier un professionnel sérieux.
Auquel cas, il faut sous-traiter aussi la vérification de la solidité du produit livré. Mais on retombe dans le problème du choix du sous-traitant B (boîte de sécu) qui évaluera le travail du sous-traitant A (développement Web).
D'ailleurs, c'est quand même marrant que seules quelques rares entités aient compris que pour pourvoir disposer de très fortes compétences en sécurité, il est mieux d'intégrer des killers que de sous-traiter à foison. Bon, OK, il faut déjà avoir une certaine surface financière pour que la question se pose, mais j'aime vraiment bien l'idée de l'équipe interne de consulting avancé, formation et R&D.
Nicob
Adrieno
Bravo Fabien pour cette belle tirade on ne peut plus pompeuse.
Je pense que dans le domaine de la sécurité, il faut savoir etre modeste et avoir un minimum d'humilité.
La pretention ne te menera nulle part.
Bravo Fabien pour cette belle tirade on ne peut plus pompeuse.
Je pense que dans le domaine de la sécurité, il faut savoir etre
modeste et avoir un minimum d'humilité.
Bravo Fabien pour cette belle tirade on ne peut plus pompeuse.
Je pense que dans le domaine de la sécurité, il faut savoir etre modeste et avoir un minimum d'humilité.
La pretention ne te menera nulle part.
Eric Masson
"Adrieno" writes:
Bravo Fabien pour cette belle tirade on ne peut plus pompeuse.
Tu réponds à un post d'Alain, pas de Fabien.
Je pense que dans le domaine de la sécurité, il faut savoir etre modeste et avoir un minimum d'humilité. La pretention ne te menera nulle part.
La prochaine fois, avant de passer pour un clown, vérifies les antécédents des personnes qui répondent à tes posts : http://www.google.com/search?hl=en&q=alain+thivillon&btnG=Google+Search
Éric Masson
-- HC> Pourquoi les dates sont de la forme "04 Feb" et non "04 Fév", comme HC> on est en droit de l'attendre sur une hiérarchie francophone ? Pourquoi il y a tant d'enculeurs de mouches fainéants sur fr.* ? -+- AT in: <http://www.le-gnu.net>- Le dino n'est pas neuneutophone -+-
"Adrieno" <adrien.dain@gmail.com> writes:
Bravo Fabien pour cette belle tirade on ne peut plus pompeuse.
Tu réponds à un post d'Alain, pas de Fabien.
Je pense que dans le domaine de la sécurité, il faut savoir etre
modeste et avoir un minimum d'humilité.
La pretention ne te menera nulle part.
La prochaine fois, avant de passer pour un clown, vérifies les
antécédents des personnes qui répondent à tes posts :
http://www.google.com/search?hl=en&q=alain+thivillon&btnG=Google+Search
Éric Masson
--
HC> Pourquoi les dates sont de la forme "04 Feb" et non "04 Fév", comme
HC> on est en droit de l'attendre sur une hiérarchie francophone ?
Pourquoi il y a tant d'enculeurs de mouches fainéants sur fr.* ?
-+- AT in: <http://www.le-gnu.net>- Le dino n'est pas neuneutophone -+-
Bravo Fabien pour cette belle tirade on ne peut plus pompeuse.
Tu réponds à un post d'Alain, pas de Fabien.
Je pense que dans le domaine de la sécurité, il faut savoir etre modeste et avoir un minimum d'humilité. La pretention ne te menera nulle part.
La prochaine fois, avant de passer pour un clown, vérifies les antécédents des personnes qui répondent à tes posts : http://www.google.com/search?hl=en&q=alain+thivillon&btnG=Google+Search
Éric Masson
-- HC> Pourquoi les dates sont de la forme "04 Feb" et non "04 Fév", comme HC> on est en droit de l'attendre sur une hiérarchie francophone ? Pourquoi il y a tant d'enculeurs de mouches fainéants sur fr.* ? -+- AT in: <http://www.le-gnu.net>- Le dino n'est pas neuneutophone -+-
Cedric Blancher
Le Thu, 12 May 2005 08:33:08 +0000, Adrieno a écrit :
Bravo Fabien pour cette belle tirade on ne peut plus pompeuse.
Tu réponds à Alain là...
Je pense que dans le domaine de la sécurité, il faut savoir etre modeste et avoir un minimum d'humilité.
Le soucis majeur de cette tirade n'est pas amha son côté éventuellement pompeux, mais surtout sa justesse. Tout ce qu'il y a là-dedans est malheureusement tellement vrai. Il est vrai que ça ne fait jamais plaisir de se faire traiter d'incompétent, mais il est un fait que si on veut faire un site web dynamique un tant soit peu sécurisé, il faudrait connaître un poil les bases de leur fonctionnement. Connaître la différence entre :
src="/secure/appli.swf"
et :
src="acces_flash.php?nom_fichier=appli.swf"
fait partie de ces bases.
-- et pis d'abord c'est quoi un dino ? une sorte de casimir avec de la guinness en guise de blouguiboulga ? -+-JFP in <http://neuneu.mine.nu> : L'île aux dinos -+-
Le Thu, 12 May 2005 08:33:08 +0000, Adrieno a écrit :
Bravo Fabien pour cette belle tirade on ne peut plus pompeuse.
Tu réponds à Alain là...
Je pense que dans le domaine de la sécurité, il faut savoir etre
modeste et avoir un minimum d'humilité.
Le soucis majeur de cette tirade n'est pas amha son côté éventuellement
pompeux, mais surtout sa justesse. Tout ce qu'il y a là-dedans est
malheureusement tellement vrai.
Il est vrai que ça ne fait jamais plaisir de se faire traiter
d'incompétent, mais il est un fait que si on veut faire un site web
dynamique un tant soit peu sécurisé, il faudrait connaître un poil les
bases de leur fonctionnement. Connaître la différence entre :
src="/secure/appli.swf"
et :
src="acces_flash.php?nom_fichier=appli.swf"
fait partie de ces bases.
--
et pis d'abord c'est quoi un dino ? une sorte de casimir avec de la
guinness en guise de blouguiboulga ?
-+-JFP in <http://neuneu.mine.nu> : L'île aux dinos -+-
Le Thu, 12 May 2005 08:33:08 +0000, Adrieno a écrit :
Bravo Fabien pour cette belle tirade on ne peut plus pompeuse.
Tu réponds à Alain là...
Je pense que dans le domaine de la sécurité, il faut savoir etre modeste et avoir un minimum d'humilité.
Le soucis majeur de cette tirade n'est pas amha son côté éventuellement pompeux, mais surtout sa justesse. Tout ce qu'il y a là-dedans est malheureusement tellement vrai. Il est vrai que ça ne fait jamais plaisir de se faire traiter d'incompétent, mais il est un fait que si on veut faire un site web dynamique un tant soit peu sécurisé, il faudrait connaître un poil les bases de leur fonctionnement. Connaître la différence entre :
src="/secure/appli.swf"
et :
src="acces_flash.php?nom_fichier=appli.swf"
fait partie de ces bases.
-- et pis d'abord c'est quoi un dino ? une sorte de casimir avec de la guinness en guise de blouguiboulga ? -+-JFP in <http://neuneu.mine.nu> : L'île aux dinos -+-
Eric Razny
Le Wed, 11 May 2005 21:29:00 +0000, Nicob a écrit :
D'ailleurs, c'est quand même marrant que seules quelques rares entités aient compris que pour pourvoir disposer de très fortes compétences en sécurité, il est mieux d'intégrer des killers que de sous-traiter à foison.
C'est clair, mais pour les petites structure des killers sont-ils nécessaires?
Surtout que dans la plupart des projet une seule personne compétante en sécu est souvant suffisante[1] (à part dans des grosses structures la plupart des projets nécessite des compétances sommes toute limitées en sécurité : fw -au sens large : architecture du reseau, gestion des DMZ etc-, web, mails, souvent CIFS/SMB, vlan et parfois sécuriser du Wifi). Pas la peine d'embaucher une armée pour ça :) Certes il serait bon d'avoir au moins deux personnes (seul une connerie peut passer plus facilement)
Ce qui est surtout dommage c'est qu'il en faut sommes toute assez peu pour être à l'abris[2] et que cet assez peu n'est souvent pas présent (accès direct au fichier vs script dans le cas présent, mais ensuite il va bien falloir faire comprendre que les params envoyés au script *doivent* être vérifiés). Il suffit de faire un google search sur des serveur disposant encore d'anciennes failles pour être fixé :-(
Bon, OK, il faut déjà avoir une certaine surface financière pour que la question se pose, mais j'aime vraiment bien l'idée de l'équipe interne de consulting avancé, formation et R&D.
Il ne s'agit pas amha simplement de surface financière mais de prise de conscience. Un simple calcul montre parfois que la réalisation d'un risque va causer des dommages bien plus important que les salaires concernés même sur 5 ans ou plus.
Et puis tient, un p'tit coup de gueule parce qu'on me l'a encore fait aujourd'hui : "le tco d'un serveur linux est supérieur à celui d'un serveur windows équivalent car un admin compétant sous linux ça coûte cher". P'tain que ce genre de discours à deux balles me gonfle. Quand on se paye un admin on met les moyens pour en avoir un compétant. Point. Et un bon admin coûte autant dans les deux cas. <provoc>Il est vrai qu'un incompétant peut faire illusion plus longtemps sous Windows que sous *nix. Mais à la première catastrophe le surcoût de la remise en état va vite dépasser la différence des salaires compétant-incompétant</provoc>
Eric.
[1] Ca suppose quand même qu'on lui donne un pouvoir décisionnel. Amha elle *doit* pouvoir dire au développeur : "là il y a un problème à corriger avant install en prod" et pas seulement dire "ce serait bien que..." :-/ Ce serait mieux une équipe sécu mais financièrement c'est quand même moins accessible :)
[2] Au moins pour la plupart des SK et des bestioles en vadrouille. Etre à l'abris d'un hacker, un vrai, c'est clairement une autre paire de manche (voir quasi impossible s'il s'est trouvé quelques exploits persos). Mais la c'est quand même rare et si on doit être la cible de ce genre de gus c'est en général que le projet vaut suffisament pour pouvoir investir dans sa protection.
Le Wed, 11 May 2005 21:29:00 +0000, Nicob a écrit :
D'ailleurs, c'est quand même marrant que seules quelques rares entités
aient compris que pour pourvoir disposer de très fortes compétences en
sécurité, il est mieux d'intégrer des killers que de sous-traiter à
foison.
C'est clair, mais pour les petites structure des killers sont-ils
nécessaires?
Surtout que dans la plupart des projet une seule personne compétante
en sécu est souvant suffisante[1] (à part dans des grosses structures la
plupart des projets nécessite des compétances sommes toute limitées en
sécurité : fw -au sens large : architecture du reseau, gestion des DMZ
etc-, web, mails, souvent CIFS/SMB, vlan et parfois sécuriser du Wifi).
Pas la peine d'embaucher une armée pour ça :) Certes il
serait bon d'avoir au moins deux personnes (seul une connerie peut passer
plus facilement)
Ce qui est surtout dommage c'est qu'il en faut sommes toute assez peu pour
être à l'abris[2] et que cet assez peu n'est souvent pas présent
(accès direct au fichier vs script dans le cas présent, mais ensuite il
va bien falloir faire comprendre que les params envoyés au script
*doivent* être vérifiés). Il suffit de faire un google search sur des
serveur disposant encore d'anciennes failles pour être fixé :-(
Bon, OK, il faut déjà avoir une certaine surface financière
pour que la question se pose, mais j'aime vraiment bien l'idée de
l'équipe interne de consulting avancé, formation et R&D.
Il ne s'agit pas amha simplement de surface financière mais de prise de
conscience. Un simple calcul montre parfois que la réalisation d'un
risque va causer des dommages bien plus important que les salaires
concernés même sur 5 ans ou plus.
Et puis tient, un p'tit coup de gueule parce qu'on me l'a encore fait
aujourd'hui :
"le tco d'un serveur linux est supérieur à celui d'un serveur windows
équivalent car un admin compétant sous linux ça coûte cher".
P'tain que ce genre de discours à deux balles me gonfle. Quand on se paye
un admin on met les moyens pour en avoir un compétant. Point. Et un bon
admin coûte autant dans les deux cas. <provoc>Il est vrai qu'un
incompétant peut faire illusion plus longtemps sous Windows que sous
*nix. Mais à la première catastrophe le surcoût de la remise en état
va vite dépasser la différence des salaires
compétant-incompétant</provoc>
Eric.
[1] Ca suppose quand même qu'on lui donne un pouvoir décisionnel. Amha
elle *doit* pouvoir dire au développeur : "là il y a un problème à
corriger avant install en prod" et pas seulement dire "ce serait bien que..." :-/
Ce serait mieux une équipe sécu mais financièrement c'est quand même
moins accessible :)
[2] Au moins pour la plupart des SK et des bestioles en vadrouille. Etre
à l'abris d'un hacker, un vrai, c'est clairement une autre paire de
manche (voir quasi impossible s'il s'est trouvé quelques exploits
persos). Mais la c'est quand même rare et si on doit être la cible de ce
genre de gus c'est en général que le projet vaut suffisament pour
pouvoir investir dans sa protection.
Le Wed, 11 May 2005 21:29:00 +0000, Nicob a écrit :
D'ailleurs, c'est quand même marrant que seules quelques rares entités aient compris que pour pourvoir disposer de très fortes compétences en sécurité, il est mieux d'intégrer des killers que de sous-traiter à foison.
C'est clair, mais pour les petites structure des killers sont-ils nécessaires?
Surtout que dans la plupart des projet une seule personne compétante en sécu est souvant suffisante[1] (à part dans des grosses structures la plupart des projets nécessite des compétances sommes toute limitées en sécurité : fw -au sens large : architecture du reseau, gestion des DMZ etc-, web, mails, souvent CIFS/SMB, vlan et parfois sécuriser du Wifi). Pas la peine d'embaucher une armée pour ça :) Certes il serait bon d'avoir au moins deux personnes (seul une connerie peut passer plus facilement)
Ce qui est surtout dommage c'est qu'il en faut sommes toute assez peu pour être à l'abris[2] et que cet assez peu n'est souvent pas présent (accès direct au fichier vs script dans le cas présent, mais ensuite il va bien falloir faire comprendre que les params envoyés au script *doivent* être vérifiés). Il suffit de faire un google search sur des serveur disposant encore d'anciennes failles pour être fixé :-(
Bon, OK, il faut déjà avoir une certaine surface financière pour que la question se pose, mais j'aime vraiment bien l'idée de l'équipe interne de consulting avancé, formation et R&D.
Il ne s'agit pas amha simplement de surface financière mais de prise de conscience. Un simple calcul montre parfois que la réalisation d'un risque va causer des dommages bien plus important que les salaires concernés même sur 5 ans ou plus.
Et puis tient, un p'tit coup de gueule parce qu'on me l'a encore fait aujourd'hui : "le tco d'un serveur linux est supérieur à celui d'un serveur windows équivalent car un admin compétant sous linux ça coûte cher". P'tain que ce genre de discours à deux balles me gonfle. Quand on se paye un admin on met les moyens pour en avoir un compétant. Point. Et un bon admin coûte autant dans les deux cas. <provoc>Il est vrai qu'un incompétant peut faire illusion plus longtemps sous Windows que sous *nix. Mais à la première catastrophe le surcoût de la remise en état va vite dépasser la différence des salaires compétant-incompétant</provoc>
Eric.
[1] Ca suppose quand même qu'on lui donne un pouvoir décisionnel. Amha elle *doit* pouvoir dire au développeur : "là il y a un problème à corriger avant install en prod" et pas seulement dire "ce serait bien que..." :-/ Ce serait mieux une équipe sécu mais financièrement c'est quand même moins accessible :)
[2] Au moins pour la plupart des SK et des bestioles en vadrouille. Etre à l'abris d'un hacker, un vrai, c'est clairement une autre paire de manche (voir quasi impossible s'il s'est trouvé quelques exploits persos). Mais la c'est quand même rare et si on doit être la cible de ce genre de gus c'est en général que le projet vaut suffisament pour pouvoir investir dans sa protection.
Adrieno
Connaître la différence entre :
src="/secure/appli.swf"
et :
src="acces_flash.php?nom_fichier=appli.swf"
Qui a nié le contraire ??? Je crois qu'il y a un quiproquo.
Connaître la différence entre :
src="/secure/appli.swf"
et :
src="acces_flash.php?nom_fichier=appli.swf"
Qui a nié le contraire ??? Je crois qu'il y a un quiproquo.
Qui a nié le contraire ??? Je crois qu'il y a un quiproquo.
Cedric Blancher
Le Thu, 12 May 2005 14:59:37 +0000, Adrieno a écrit :
Connaître la différence entre : src="/secure/appli.swf" et : src="acces_flash.php?nom_fichier=appli.swf" Qui a nié le contraire ???
Que ce soit une base, personne. Que tu ais compris cette base, pas mal de gens, au regard de la réponse que tu as servie à Julien précédemment. Et s'en suit la tirade d'Alain.
Je crois qu'il y a un quiproquo.
C'est possible, mais j'ai comme un doute...
NB : Quand on cite les gens, on préfixe la ligne avec un caractère spécial, usuellement ">", pour différencier la citation de sa propre prose. C'est plus facile à lire pour les autres.
--
et pour Suse tu dirais quoi ? Euh ... Suseuses ?
Flo redhateuse ... ou redhatienne ... ou redhatisée -+- Flo in Guide du Fmblien Assassin : "Tu suse ou tu redhatte ?" -+-
Le Thu, 12 May 2005 14:59:37 +0000, Adrieno a écrit :
Connaître la différence entre :
src="/secure/appli.swf"
et :
src="acces_flash.php?nom_fichier=appli.swf"
Qui a nié le contraire ???
Que ce soit une base, personne. Que tu ais compris cette base, pas mal de
gens, au regard de la réponse que tu as servie à Julien précédemment.
Et s'en suit la tirade d'Alain.
Je crois qu'il y a un quiproquo.
C'est possible, mais j'ai comme un doute...
NB : Quand on cite les gens, on préfixe la ligne avec un caractère
spécial, usuellement ">", pour différencier la citation de sa
propre prose. C'est plus facile à lire pour les autres.
--
et pour Suse tu dirais quoi ?
Euh ... Suseuses ?
Flo redhateuse ... ou redhatienne ... ou redhatisée
-+- Flo in Guide du Fmblien Assassin : "Tu suse ou tu redhatte ?" -+-
Le Thu, 12 May 2005 14:59:37 +0000, Adrieno a écrit :
Connaître la différence entre : src="/secure/appli.swf" et : src="acces_flash.php?nom_fichier=appli.swf" Qui a nié le contraire ???
Que ce soit une base, personne. Que tu ais compris cette base, pas mal de gens, au regard de la réponse que tu as servie à Julien précédemment. Et s'en suit la tirade d'Alain.
Je crois qu'il y a un quiproquo.
C'est possible, mais j'ai comme un doute...
NB : Quand on cite les gens, on préfixe la ligne avec un caractère spécial, usuellement ">", pour différencier la citation de sa propre prose. C'est plus facile à lire pour les autres.
--
et pour Suse tu dirais quoi ? Euh ... Suseuses ?
Flo redhateuse ... ou redhatienne ... ou redhatisée -+- Flo in Guide du Fmblien Assassin : "Tu suse ou tu redhatte ?" -+-
