marlou knowledge base

# security webapp

# ANSSI guides

Sécuriser un site web

Les recommandations de ce guide concernent la sécurité des contenus présentés par un navigateur web aux utilisateurs. Les sujets abordés se concentrent autour des standards du Web, dont les implémentations côté navigateur requièrent des paramètres à spécifier lors du développement et de l'intégration d'un site ou d'une application web, de façon à en garantir la sécurité.

Après avoir exposé les menaces et classes d’attaque récurrentes, puis rappelé les règles d’hygiène en matière de sécurité Web, le guide « Recommandations pour la mise en œuvre d’un site web : maîtriser les standards de sécurité côté navigateur » décrit et détaille la mise en œuvre des mécanismes de sécurité mis à disposition par la plateforme web. Est notamment rappelée la contrainte de Same Origin Policy (SOP) et son mécanisme de relâchement Cross Origin Resource Sharing (CORS). Le guide aborde ensuite certaines pratiques de protection contre le Cross Site Scripting (XSS) telles que SubResource Integrity (SRI) puis la communication inter-contextes en général, en détaillant notamment les standards Content Security Policy (CSP), Referrer-Policy, et les pratiques relatives au cloisonnement telles que le choix et le paramétrage des moyens de stockage côté client (ex. : cookies, Web Storage) et des moyens d’isolation des ressources actives (ex. : iframes, Web Workers).

Guide ANSSI - Recommandations pour la mise en œuvre d’un site web : maîtriser les standards de sécurité côté navigateur

# Top 10 OWASP (10 risques de sécurité les plus critiques)

# 1 - Injection

SQL, LDAP, XPath, Parseur XML, ...

# Exemple avec SQL

Saisir dans un champ de saisie de mot de passe :

e' or '1' = '1
1

# Exemple avec XML

<?xml version="1.0" encoding="ISO-8859-1"?>
    <!DOCTYPE foo [
        <!ELEMENT foo ANY >
        <!ELEMENT xxe SYSTEM "file:///etc/passwd" >]>
    <foo><&xxe;</foo>
1
2
3
4
5

# 2 - Violation de gestion d'authentification et de session

L'authentification devrait être déléguée à un service tiers (Kerberos, OAuth, JWT, ...)

La session devrait être gérée via un cookie :

set-cookie:MonCookie="XXXX";Version=1;Secure;HttpOnly
1

# 3 - Exposition de données sensibles

Protection par cryptographie.

Analyse des données (stockées ou pas)

Mot de passe : bcrypt, PBKDF2, scrypt (hash solo trop faible)

# 4 - Cross-Site Scripting (XSS)

Cross-site Scripting (XSS) : owasp.org

Cross-site scripting attacks may occur anywhere that possibly malicious users are allowed to post unregulated material to a trusted web site for the consumption of other valid users.

The most common example can be found in bulletin-board web sites which provide web based mailing list-style functionality.

XSS (Cross Site Scripting) Prevention Cheat Sheet : owasp.org

AngularJS gère en natif ce problème (sanitize).

Vectors making use of HTML5 features

# 5 - références directes non sécurisées

http://example.com/app/accountInfo?acct=notmyacct
1

Pour taper sur un autre compte par exemple.

Autre exemple, usage d'autoincrements SQL comme ID REST.

Applicativement il faut s'assurer qu'un user ne reçoivent que les données auxquelles il a accès.

Remplacer également les id SQL par des uuid.

# 6 - mauvaise config secu

Taf des devops. Config OS, middleware, réseau, remplacement des mdp par défaut, etc ...

Question dev attention aux logs.

# 7 - Manque de contrôle d'accès au niveau fonctionnel

RBAC à impl. Un user lambda ne doit pas accéder à l'administration de l'app.

# 8 - Falsification de requête interdite (CSRF)

  • vérifier que la requête est "Same Origin" (headers standards)
  • config & impl CORS
  • utiliser un token spécifique (Double cookie defense via XSRF-TOKEN)

Exemple d'attaque :

  • user se connecte sur le site de sa banque utilisant un cookie pour gérer la session
  • user effectue quelques actions (check des comptes etc ...)
  • user ne se delog pas
  • user clique sur un lien lolcat reçu en mail. La page web chargée effectue un call sur le site de la banque de user pour effectuer une transaction. Si CORS n'est pas configuré par la banque alors le navigateur transmettra le cookie de session toujours valide avec le call du site frauduleux et sa transaction sera acceptée.

CORS configuration is server-side.

A server using "Access-Control-Allow-Origin: *" allows all domains, it is very bad.

What are the security risks of setting Access-Control-Allow-Origin? : stackoverflow.com

By responding with Access-Control-Allow-Origin: *, the requested resource allows sharing with every origin. This basically means that any site can send an XHR request to your site and access the server’s response which would not be the case if you hadn’t implemented this CORS response.

So any site can make a request to your site on behalf of their visitors and process its response. If you have something implemented like an authentication or authorization scheme that is based on something that is automatically provided by the browser (cookies, cookie-based sessions, etc.), the requests triggered by the third party sites will use them too.

# 9 - Utilisation de composants avec des vulnérabilités connues

OWASP publie un composant MAVEN nommé dependency-check-maven pour check les vulnérabilités de son projet par ex.

13 tools for checking the security risk of open-source dependencies

# 10 - redirections et renvois non validés

http://www.example.com/redirect.jsp?url=evil.com
1

Par exemple si on permet aux users la saisie de liens (forum par ex), difficile de valider le lien de redirection.

# autres attaques

# ReDoS

Regular expression Denial of Service - ReDoS

En fonction du pattern de la regex et de l'input donnée par l'utilisateur, il est possible de générer un cout CPU disproportionné. S'il y a plusieurs serveurs qui se passent la data et qu'ils checkent tous la data avec une regex, l'attaque peut toucher plusieurs machines. Contrairement à une DDoS classique dont le but est de noyer le serveur sous les requêtes, il s'agit ici de noyer le(s) serveur(s) sous le cout de calcul CPU.

Exemple de ReDoS sur moment.js.

# ressources

OWASP : the free and open software security community

Protéger son application web des risques de sécurité les plus critiques (Pascal Abaziou) Devoxx2017

← Authentification →