NOTA AVANT DE LIRE
-----------------------------
J'ai ouvert ce topic pensant qu'au bout de 3 jours Elmoricq m'aurait encore giclé comme à la grande époque du parser de google... Finalement ça part bien, y'a des rigolos bien sur, mais dans l'ensemble la discussion est constructive et je dois avouer que j'y apprends beaucoup.
Donc le site que je soumets à la torture est une création personnelle, sur mon temps libre, je tiens à le préciser, je ne suis pas Webmaster de métier, loin de là, même si je touche bien dans certains domaines (VB essentiellement) je ne considère absolument pas maitriser le PHP et j'ai horreur des réponses du style : "Trop facile : ftrqzpt(x -y²) " (je dis ca pour ceux qui ne concoivent pas que l'on ne puisse pas savoir ce qu'ils savent et qui s'empressent de vous montrer qu'ils le savent)
En attendant, encore une fois, merci à tous ceux qui ont essayé de pétarder le site (je dois avouer qu'à un moment j'ai bien eu du mal à lire les logs   ) et j'espère que ce topic en aidera d'autres...
S'il te plait Elmo, Dieu vivant du cadenassage de topic, let il live !!!
-----------------------------
Donc voilà le sujet d'origine
-----------------------------
Oups !!!
Je viens de lancer mon petit site...
Par conscéquent je lui donne l'épreuve du feu...
allez-y ! critiquez, de façon constructive, y'en a quand même pour quelques heures de boulot !
Merci
http://pulbot.free.fr/index.php

http://pulbot.free.fr/demande_000.php?choix=studio
 
Magnifique.

T'affiche tout le code HTML dans des echo Pas bien

 
ouf... en cours de sauvetage !!!
merci

 
Tu peux m'expliquer ?
disons qu'en général ça me permet de passer des variables sur tout le long du code et ainsi je garde tout le code en PHP, je veux dire que je fais pas un truc du genre
HTML
PHP
HTML
PHP... Merde j'ai perdu mes variables

pulbot.free.fr//offre_000.php?jesuis="><script>alert(document.cookies)</script>&choix=commerce

injection SQL...
Pfffffff trop classique !

Il manque énormément de vérification au niveau de ce qu'on met dans les URL

Pas SQL, HTML.

exact lol
bon j'ai commencé à betonner un peu, ça beugue un peu moins !

Quand on créé ou recherche une offre :  
1) A l'heure actuelle les deux premières pages de formulaires ne devraient en faire qu'une : rien de visible de l'extérieur ne justifie d'avoir le type de bien séparé du reste vu que ce choix n'a pas l'air d'influencer les éléments de la page suivante.
 
2) Les boutons "publier cette annonce" "retour au sommaire" ... ne se voient quasiment pas. On dirait du texte et du coup ça donne l'impression d'être sur un formulaire sans bouton. On se retrouve obliger de lire le texte explicatif pour savoir ce qu'il faut faire ce qui est anti ergonomique.
 
3) L'absence de contrôle. Vu que t'as juste passé quelques heures sur ton site c'est comme si c'était une maquette et du coup c'est normal qu'il n'y ai quasiment aucun contrôle. Par contre j'ai pourri ta base du coup avec une offre situé nulle part.
 
La section agence :
C'est une section pour les professionnels et par conséquent on s'attend à ce qu'il y ai un plus dans cette section par rapport à la section "particulier". Par exemple avoir la possibilité de mettre en ligne plusieurs offres en une seule fois ou encore avoir la possibilité de créer un compte permettant de s'identifier et de modifier ensuite les annonces qu'on a posté. Ca serait bien de leur proposer ce genre d'options. Si les sections particulier et agence sont identique alors il n'est pas très utile de les garder séparé. J'imagine que c'est prévus mais pas encore fait.
 
Un dernier détail assez comique : on peut indiquer une surface quand on cherche des annonces ... mais on ne peut pas indiquer de surface quand on en créé (ou alors j'ai mal vu).

je viens de rentrer une annonce sans saisir un seul champ

Ca lui en fait donc deux comme ça dans sa base.

accessoirement, j'aimais mieux l'ancien design
il était pas terrible, mais là il fait franchement "mode debug"

Arfffffffff
Yes c'est un peu le mode debug mais coté design je suis pas fortiche...
Bon soit ! il faut encore que je fasse des vérifications !
merci à tous

Woua, d'ici un mois ca va etre à mon tour de faire passer mon projet à l'epreuve du feu ...
Je vais en prendre plein la g.....
 
Mais bon c'est une étape obligé
 
Sinon courage erwan83 et félicitation de proposer des produits gratuit (open source ?)
 
edit : la seul critique que je peu faire de ton site c'est qu'il ne ce fait pas valider au W3c

 
Heu et pourquoi donc ? et quelle est l'importance de cette norme W3C ? Standard obligé ?
Sinon, lol j'ai résolu le problème des petits malins qui postaient des annonces vides !!!
Merci encore à tous les crackers, buggueurs qui ont tenté de claquer mon code !!! ce fut sympa à dépanner
Heu... connaitriez pas un graphiste ou un type qui gaze en CSS ???

Sans cette norme, ça serait le bordel pour obtenir des sites web qui s'affichent bien dans tous les navigateurs (déjà que c'est le bordel) vu que chacun ferait sont petit manège de son côté.
Moi, ça ne me choque pas quand des sites ne passent pas l'étape de la validation, par contre ça serait bien que tu jettes un oeuil ici pour corriger les problèmes de guillemets manquants et les valeurs non normalisés des attributs (potentiellement non traité par certains navigateurs). Ca serait bien aussi que tu normalises aussi tes balises (un coup tu fermes les meta avec "/>" et un coup sans le "/" )
 
Je n'avais pas trop regardé le code html, mais je te conseille de toujours mettre un doctype à tes pages. Ca t'éviteras de te retrouver avec des marges géré différemment par IE que par les autres navigateurs même si ça bloque certaines valeurs non standards pour certains attributs (ce qui n'aurait été reconnus que par IE de toute manière)  
 
En bref, c'est pas obligatoire mais c'est une aide qui évite plus tard pas mal d'embrouille au niveau affichage sur les différents navigateurs : c'est déjà assez compliqué pour ne pas tout compliquer intentionellement (ou pas).

 
http://openweb.eu.org/articles/pourquoi_standards/  
 
Rien d'obligatoire, mais c'est mieux    
Les navigateurs respectent de plus en plus les standard, même ie commence à s'y mettre.
Si ton site respecte aussi les standards tu aura moins d'affichage "bizarre" selon les navigateurs
et avec tous ces nouveaux navigateurs (safari, Chrome, ie8) il ne va plus etre possible de tester ton site sur toutes les plateforme
 
De plus il m'avait semblé que les pages standardisées s'affichaient plus vite et j'ai en effet trouvé des infos relantant cette info (meme si je trouve les chiffres un peu élévé) :

source : http://www.icom-communication.fr/fr/standards-w3c.html
 
a+

Merci beaucoup pour le tuyau !

http://validator.w3.org/
http://jigsaw.w3.org/css-validator/
 
Sont les deux sites de référence pour valider ton code.
Le but est d'obtenir 0 erreur et 0 avertissement.
C'est super simple si tu codes bien, et dans tous les cas les erreurs sont généralement simples à corriger.

Vérifies aussi que les données que tu recois appartiennent bien au domaine attendu (surtout pour les "<select>" ).
 
Sinon tu risques de t'exposer aux failles de cross site scripting (XSS) qui sont très méchantes : le vilain recopies ton formulaire d'inscription en local, ajoute une "<option>" au "<select>" et le valide en local, ce qui redirige bien sur vers ta base de données car il n'a pas changé le "action" du "<form>"... et poum tu as une offre complètement pourrie dans ta BD.

A priori, pour le moment je n'ai pas encore fait labascule chez l'hébergeur, ça ne marche pas, les données ne peuvent venir que de chez l'hébergeur, à moins que tu ne parles d'une attaque sur la page d'action du formulaire ?

CyberDenix > Si tu parles de se baser sur le HTTP_REFERER alors ça ne sert à rien. C'est une donnée qui est tellement simple à falsifier (comme tous ce qui est envoyé par un navigateur) que se baser dessus c'est mettre en place une fausse sécurité (on se croit protégé alors que ça n'est pas le cas).
Ce qu'il faut faire, c'est vérifier la validité de toutes les données qu'on utilise que ça soit au niveau du type de donnée (nombre, chaine de caractère, ...) et/ou au niveau de la validité par rapport aux données de la base (Est ce que le département indiqué correspond à ceux qu'on connait?) et/ou grâce à des règles de contrôle plus complexes (validation par masques, par algorithme, ...)

en gros il faudrait presque "modérer" toutes les annonces avant de les publier ?

Ben désolé mais tu as mal vu...  

C'est erwan83 qui émet cette hypothèse, pas moi !    
 
 

En quelque sorte, mais pas manuellement.
Il doit y avoir un contrôle de toutes les données entrantes (et particulièrement celles saisies dans des formulaires à destination d'un stockage dans la BD) afin de vérifier que les données que tu reçoies sont bien dans le domaine/l'intervalle/la liste des possibilités attendus.
Comme ça si un gros malin t'attaque avec une faille XSS, tu seras à même de sniffer la tentative d'injection de valeurs indésirables, et donc de poliment rediriger vers la page du formulaire en invitant le grossier personnage à retenter sa chance (Il parait qu'on a tous le droit à un Joker...   ).
 
 

C'est effectivemmment ça !  
 
Je rajouterai que la base de l'informatique orientée utilisateur, c'est : "NEVER TRUST THE USER INPUT"  

Bon, pour résumer!!!
1/ je dois vérifier toutes les données (déjà quelques champs TEXT sont formatés)
2/ le problème que je me pose c'est que, si un gros malin désire marquer "vends poupée gonflable très peu servi" rien ne l'en empêche, vous voyez le genre de gag ?  
comment contourner ça ?

exemple, si je suis un petit malin et que je tape  
http://pulbot.free.fr//offre_000.p [...] x=commerce
par exemple
ben, z'avez qu'à aller voir ! ca marque un gentil message...
mais ce n'est qu'une possibilité, je me trompe ?

On peut sauter ta pagination par injection SQL :
 
http://pulbot.free.fr/demande_004. [...] =0,1000;--
 
Edit : injection possible ici aussi
 
http://pulbot.free.fr/demande_002. [...] _affiche=5

Wahou c'est chaud
bon, au boulot et merci CyberDenix

 
Euh, pas du tout non

http://fr2.php.net/strip-tags à l'affichage peut être une solution.
 
 

Merci yellu pour ta contribution !
 
Effectivement l'injection SQL c'est très mal, je te conseille d'utiliser http://fr.php.net/pdo (PHP Database Objects) qui est super pour ca.
En fait depuis PHP 5, c'est l'unique mode de connexion aux BD officiel (mysql_* et consors sont dépréciés).
 
Regarde un petit exemple sur la doc PHP, les paramètre avec les '?' sont échappés automatiquement :
 

<?php
//...
/* Execute a prepared statement by passing an array of values */
$sth = $dbh->prepare('SELECT name, colour, calories
                      FROM fruit
                      WHERE calories < ? AND colour = ?');
 
$sth->execute(array(150, 'red'));
$reds = $sth->fetchAll();
 
foreach ($reds as $red) {
  echo $red['name'].'<br/>';
}
?>

Bon, grand merci, merci aux accros des bugs qui decalent l'affichage, qui font sauter les compteurs...
je continue à renforcer...
 
liste des pages à attaquer :
http://pulbot.free.fr/demande_004.php?region=sud_ouest
(par exemple)
http://pulbot.free.fr/demande_002.php
merci !!!
(il est fou)

pas vraiment, non ...
 
echo strip-tags('<scri<script>pt type="text/javascript">blabla'); ...

Chez moi

echo strip_tags('<scri<script>pt type="text/javascript">blabla');

fonctionne parfaitement ?

echo strip_tags('<scri<script>pt type="text/javascript">blabla');

La vraie solution, c'est htmlspecialchars()

et tu penses que cette fonction permet d'enlever les " % ù ^ - + < > etc etc ???  
pas si sur
 
le vrai soucis c'est d'éviter ça :
http://pulbot.free.fr/demande_002. [...] ax=9999--;
dans ce lien j'ai rentré exprès toutes les "vacheries" du genre -- ou ; ou %... ou autre encore
alors, la vraie question est d'éviter, enfin, de contourner toutes ces "injections" de caractères parasites
pour le moment je controle l'URL qui est demandée mais ce n'est pas assez ...

Bien mieux que ça, elle ne les enlève pas mais les rend inoffensives C'est la solution pour les injections XSS.

Pour les injections SQL, la solution est mysql_real_escape_string() ou équivalent, ou les requetes préparées. Tu m'envoie un ' OR admin=TRUE; -- Alors on va écrire la chaîne " ' OR admin=TRUE; -- " dans la base Et ça va pas pirater la requète.

Après tout, si ça se trouve le mec s'appelle vraiment " ' OR admin=TRUE; -- "

(et au passage, les apostrophes feront plus jamais foirer les requetes \o/)

 
Bon quelques explications :
 
1-stripstags() : supprimer le code HTML d'une chaîne (permet d'éviter les failles XSS) mais empêche l'utilisateur de placer certains signes car ils seront carrément supprimés.
2-htmlspecialchars() : échapper le code HTML d'une chaîne pour empêcher son interprétation par le navigateur.
C'est aussi sûr que la fonction précédente, et bien moins lourd.
3-mysql_real_escape_string() : échapper le code (my)sql d'une chaîne pour éviter les injections SQL (le problème qui te préoccupe).  
 
(2) doit être utilisé à l'affiche et (3) à l'enregistrement. (avant entrée en base).