Discussion :

[redoran]

Salut ; voila au bout certain moment j'ai terminé ma première application web avec l'appui des forumeurs. certes y'avait beaucoup d'insuffisances
je veux resté sur le plan sécurité:
application de type d’apprentissage qui tourne en locale,
pour la connexion j'utilise PDO,
accès sécurisé par user , mot de pass et captcha,
cryptage du mot de passe : aucun faute de choix de méthode ( MD5 ou autres..)
Mise a jour des données avec des requêtes préparées,
les pages du site sont géré de tel sorte une fausse URL renvoi vers la page d’authentification,

je sais que c'est pas suffisant contre les risques les plus sérieux et cela par ignorance , donc si je simule le risque d'attaque d'une application web par rapport a une pathologie (maladie ) vue mon domaine:
attaquant ==> vecteur/véhicule ==> brèche ==> organe cible.

je crois que la sécurité d'une application web doit être pensée avant le développement et afin de parvenir Comment peut on listé les risques?

[redoran]

salut ; avant de répondre a cette question , je crois que la sécurité d'une application web touche l'humain , le matériel et le soft.
donc si je reste sur le soft et précisément l'application web:

• Le développeur prend en charge le coté sécurité de l'application ( code source)
• la formule : connaitre le risque = développez barrière

Connaitre le risque:
Une bonne lecture autour des risques liés aux vulnérabilités des applications web sur le net permet grandement d'avoir une vue d'ensemble sur les phénomènes d'attaques, et de ce développez un plan de sécurité.
partant de la frontière entre le net et l'application web (structure et contenu) , dans mon cas c'est :

1. adresse URL,
2. L'interface d’authentification porte d'entrée,

pour mois sa représente les deux entrés possible par l'attaquant.
mesures prises:
pour les gestion de l'URL : j'ai développé un petit code PHP de redirection vers la page authentification dans le cas ou l’attaquant entre l'adresse exemple www.monsite/admin ou autre user.
les mots communs comme admin user jamais utilisé dans mon site.
le contrôle de l'authentification ( utilisateur - mp) se fait par du code PHP + requêtes préparées + desactivation de l'auto-completion.
le crypatge du mot de passe est en instance ( actuellement je me documente sur la meilleur méthode).
avant de continué est ce que je suis dans la bonne voie ?

[grunk]

Un peu de lecture : http://owasptop10.googlecode.com/fil...0%20French.pdf

[redoran]

Re; merci grunck génial

[redoran]

salut ; suite a l'orientation de grunk voila le constat:
mon but été d'arrivé a une programmation sécurisée, ma démarche est la suivante:
mise en place d'un fichier .htaccess pour protégé les répertoires,
pour la protection de la chaine de connexion (PDO) , j'ai pas pus su faire !
ligne de défense contre les dix risques de sécurité applicatifs web ( OWASP)


A1-injection sql:
contrôle stricte par PHP le nombre de caractères des champs du formulaire d’authentification,
utilisation des requêtes préparées,

A2 –Cross-Site Scripting (XSS):
script de vérification en PHP des paramètres de l'URL

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
 
<?php
.....
// On définit le tableau contenant les pages autorisées
  // ----------------------------------------------------
$navok = array('bord' => 'bord.inc.php',
                      'dec' => 'aff.inc.php',
                       'anal' => 'anal.inc.php',
		        'mp' => 'mp.inc.php',
		        );
// On teste que le paramètre d'url existe et qu'il est bien autorisé
// -----------------------------------------------------------------
if ( (isset($_GET['page'])) && (isset($navok[$_GET['page']])) ) {
$page = htmlentities($_GET['page']);
include($navok[$page]);   // Nous appelons le contenu central de la page
} 
else {
// Page par défaut quant elle n'existe pas dans le tab
include('bord.inc.php'); 
 
}

A3 -Violation de Gestion d'Authentification et de Session:
l'attaque par force brute pousse le serveur a généré des erreurs , ces dernières seront exploités par le hakers.
afin de paliers a ces attaquent ; jai realisé en php un script de tentative d'accés en 3 essais.
génération de messages d'erreurs générique " erreurs authentification...",

A4-Références directes non sécurisées à un Objet:
contrôle stricte par PHP le nombre de caractères des champs du formulaire d’authentification,
utilisation des requêtes préparées,

A5 -Falsification de requête intersite(CSRF):
surveillance des URL

A6-Mauvaise configuration Sécurité:
concerne le serveur et les applications installées,

A7-Stockage Cryptographique non Sécurisé:
pour le mot de passe je cherche toujours une bonne méthode de cryptage réversible.

A8 -Manque de Restriction d’Accès URL:
même solution que A2

voila je suis arrivé a ce niveau , c'est tous ce que j'ai pus faire

[grunk]

A2 : XSS

Ce n'est pas suffisant, tu dois également échapper tout ce qui est afficher sur une page (htmlentites ou htmlspecialchars).
Sinon un utilisateur s'enregsitre avec <script>alert('xss')</script> comme login et dès que son pseudo sera afficher sur le site , cela exécutera le code.

A5 : CSRF

Insuffisant également. Tu dois mettre en place un système de token qui permet d'être certains qu'une requête viens bien de ton site.
Par exemple pour un formulaire :
- A l'affichage du formulaire , générer un token que tu place en session et dans un champs hidden du formulaire
- Au traitement du formulaire , tu vérifie que le token reçue par get ou post correspond à celui en session et que sa durée de vie n'est pas expirée.

Tu peux voir un exemple de classe gérant celà ici : https://github.com/grunk/Pry/blob/ma...oken.class.php
un exemple d'utilisation dispo là : http://pry.oroger.fr/doc/ (choisir Util => token dans le menu)