JeuWeb Créez votre jeu par navigateur !

Roworll · 25-07-2013, 01:54 PM

(25-07-2013, 01:25 PM)niahoo a écrit : ben oui parce que s'il y a un problème ton PDG il veut pouvoir virer quelqu'un, moi non.

Je ne pense pas que l'idée derrière la déclaration de ce PDG soit la notion de coupable et de licenciement. Il met au contraire le doigt sur un truc tout simple mais particulièrement chiant.

Prenons l'exemple d'une application web, avec serveur et base de données.
Si l'application est lente, le développeur aura tendance à accuser le réseau ou la base de donnée. Le DBA remettra en question le réseau ou l'application. Les ingénieurs réseau suspecteront l'application ou la base de données.
Que la démarche soit sincère ou pas, chacun tentera de passer la patate chaude au camp d'en face.

J'ai exactement ce problème actuellement au boulot.
On a des développeurs externes qui font de la merde en barre et tentent de foutre ça sur le dos de l'infrastructure, de la base de données et/ou des autres composants. J'ai rarement vu une telle mauvaise foi...
Ce genre de comportement est un véritable soucis car il entraîne un gaspillage de ressources, ne serait-ce que pour démonter leur allégations. Et même le nez dedans, ils sont capable de te soutenir que l'odeur n'est pas si désagréable.

Donc, pour se remettre dans le contexte, imagine ce genre de situation autour d'un double module de sécurité défaillant réalisé par des dev différents...

**Xenos** · 25-07-2013, 02:58 PM

D'autant que si on met une double vérification ici, on peut en mettre de la même façon partout... Qu'est ce qui te dis que le header n'a pas été intercepté par un pirate? Il faudrait un check par téléphone. Et si le pirate peut injecter des données dans les headers du serveur? Il faut un autre check sur le serveur... on n'a pas fini de faire des checks! S'il faut 1 ligne de check pour chaque ligne de code (y compris les lignes de check elles-mêmes?! Infinite loop spotted), alors on n'est pas rendu Confused

.

Si on n'est pas capable de garantir qu'il n'existe pas d'injection sur un site (pour ECLERD, je n'en aucune idée, car le développement de ce jeu a été chaotique et bien plus proche de l'apprentissage que du release), alors on n'est pas capable d'en garantir la moindre sécurité.
Un site bien fait (j'ai jamais dit que ECLERD l'était :p les extra-terrestre étant toujours friant de l'enlèvement d'humains) n'a pas d'injection, point barre.

Enfin, n'oublions pas que ces spécifications sont à destination de tout le web, et non des petits développeurs indépendants. Si un choix de spécification déplait aux petits développeurs mais est compatible avec les grandes entreprises alors ce choix sera privilégié, face à un autre choix qui plairait aux petits développeurs, mais serait incompatible avec les grandes boites (plaire vs compatibilité étant la clef du choix).

**niahoo** · (Modification du message : 25-07-2013, 04:00 PM par niahoo.)

non mais stop, ce n'est pas une double sécurité, c'est une sécurité qui fonctionne en deux parties. C'est comme les sécurités à clé privée/clé publique, on n'imagine pas des gens dire que c'est idiot parce que ce ne sont pas les mêmes personnes qui sont responsables de la clé de leur côté ....

Citation :Un site bien fait n'a pas d'injection, point barre.

que dire à part "lol". Tiens ça me rappelle une discussion récente, je pourrais également dire "ça c'est de l'argument !", effectivement cela résout tous nos problèmes.

Mais ma bonne dame, si vous voulez une sécurité exemplaire, faites votre site "bien". Voilà c'est 500 €, merci aurevoir.

Donc bon de toute façon on sera pas d'accord, vous voyez un double module de sécurité réalisé par des devs différents et des responsabilités à gérer dans des grandes entreprises. Perso je cherche à développer un jeu en solo ou à 3 ou 4, et ici il ne s'agit pas d'un module mais de simples whitelists. C'est le navigateur qui se charge de sécuriser ça, pas moi ou mes éventuels collègues devs.

Donc bon je vous laisse discuter de la sécurité chez google, microsoft, facebook, le FMI ou le FBI pis moi je vais chercher comment on met en place un partage de ressources sécurisé. (sachant que dans le cadre d'un échange sécurisé ça me semble logique qui la sécurité soit gérée des deux côtés - Votre banque sécurise votre CB mais vous devez sécuriser votre code, ne pas l'écrire sur la carte par exemple).

**Xenos** · 25-07-2013, 04:53 PM

Ouais, ok, l'argument n'est franchement pas étoffé, mais les spécifications sont ainsi rédigées. Si la spécification devait se dire "mais si le serveur 1 n'est pas tout à fait intègre, je fais quoi?", alors elle ne ferait pas 50 mais 5.000 pages.

Citation :c'est une sécurité qui fonctionne en deux parties.

Alors, c'est que je n'ai pas compris ton propos. Là, pour moi, tu as:
- Une sécurité car le serveur 1 envoie le code javascript disant "hé, navigateur web, va demander tel truc à serveur 2 et laisse-moi le lire"
- Une sécurité car le serveur 1 envoie ton header http disant "hé, navigateur, j'ai le droit de t'envoyer chercher des trucs uniquement sur serveur 2"

Et les deux ne sont pas complémentaires, mais redondantes: en l'absence de code javascript, le navigateur ne va pas interroger serveur 2. La 2e sécurité est donc un second verrou inutile, puisque le premier est suffisant.
Alors, peut-être t'es-tu mal exprimé, ou peut-être n'ai-je pas tout compris?

**niahoo** · 25-07-2013, 05:18 PM

(25-07-2013, 04:53 PM)Xenos a écrit : Ouais, ok, l'argument n'est franchement pas étoffé, mais les spécifications sont ainsi rédigées. Si la spécification devait se dire "mais si le serveur 1 n'est pas tout à fait intègre, je fais quoi?", alors elle ne ferait pas 50 mais 5.000 pages.

Ben tu fais ce que je propose, tu mets en place la seconde partie de cette sécurité en plus de CORS.

(25-07-2013, 04:53 PM)Xenos a écrit : - Une sécurité car le serveur 1 envoie le code javascript disant "hé, navigateur web, va demander tel truc à serveur 2 et laisse-moi le lire"

Oui

(25-07-2013, 04:53 PM)Xenos a écrit : - Une sécurité car le serveur 1 envoie ton header http disant "hé, navigateur, j'ai le droit de t'envoyer chercher des trucs uniquement sur serveur 2"

Tu décris exactement deux fois la même chose. C'est le serveur 2 qui balance le header dans la seconde partie, dans CORS.

(25-07-2013, 04:53 PM)Xenos a écrit : ... en l'absence de code javascript ...

ah ben oui. D'ailleurs si ton jeu n'est pas sur internet non plus et que c'est un livre, c'est sur, c'est méga redondant :p. Je me moque mais ceci dit tu peux injecter du javascript dans une base de données, y a pas besoin que le jeu en lui même soit basé sur javascript.

**Xenos** · 25-07-2013, 06:01 PM

Oui, dans CORS, c'est justement bien fait, ca, je suis d'accord, et dans CORS, oui, c'est une sécurité partagée et non double.
Moi, j'avais compris que tu reprochais à CORS de ne pas demander à serveur 1 d'envoyer un header qui explicite l'autorisation au navigateur d'accéder à serveur 2.

Citation :Pourquoi est-ce que ce n'est pas superjeu.com qui indique dans les headers de réponse qu'il autorise des requêtes ajax ou autre à partir vers superjeu-static.fr:8000 et surtout pas vers un autre domaine ?

Ca, ce serait le cas que j'ai décrit, de double-sécurité, redondante et inutile.
Alors que CORS, justement, fais le contraire en demandant à serveur 2 d'accepter les requêtes de serveur 1. Là, c'est une bonne sécurité partagée et non une sécurité redondante.

La sécurité de CORS est donc bien fichue, mais celle que tu proposes (et que j'ai re-décrite alors avec ces deux tirets) est redondante et inutile car oui, ces deux sécurités décrivent 2 fois la même chose.

**niahoo** · (Modification du message : 25-07-2013, 07:44 PM par niahoo.)

mais je dis pas que CORS est mal fait, je dis qu'il manquerait l'autre sens. relis mon premier post et tu verras qu'il n'y a rien de redonant.

Citation :Pourquoi est-ce que ce n'est pas superjeu.com qui indique dans les headers de réponse qu'il autorise des requêtes ajax ou autre à partir vers superjeu-static.fr:8000 et surtout pas vers un autre domaine ?

Donc si tu relis mon premier post tu verras qu'en cas de requête non désirée on ne touche pas au serveur B. donc il peut avoir sa super sécurité pas redondante tout ce que tu veux, comme il n'es plus dans le coup ben ça sert à rien.

Enfin c'est pas bien compliqué quand même ... C'est pas redondant, ta banque autorise seulement ta CB à retirer de l'argent et toi seul peut activer ta CB parce que tu as le code. enlève une des deux protections sur un sens de l'échange et l'autre devient également inutile car hors du coup. (si n'importe qui peut utiliser ta CB (sous réserve qu'il fasse une petite injection dans ton poirtfeuille, alors ça devient inutile que la banque n'autorise que ta CB à retirer sur ton compte. Si n'importe quelle CB peut récup de la thune sur ton compte, ton code à 4 chiffres tu peux t'en faire un porte-livres Big Grin

)

non mais peut-être que je délire et que je dis n'importe quoi hein, faut pas trop prendre tout ça au sérieux.

enfin, pour être plus précis, dans mon premier post je demandais effectivement pourquoi ce n'était pas l'inverse de CORS qu'on faisait, mais vous m'avez démontré que CORS était utile en soi. Je ne me plaçais que du point de vue de A et pas de celui qui partage ses ressources.

Mais ensuite on a commencé à débattre de l'utilité de la méthode inverse *en plus* de CORS, bon j'ai toujours pas cheché mais il y a moyen de gérer les domaines étrangers facilement on dirait.