Valider et non pas juste parser !

La plus importante manière d’eviter une injection est de valider une donnée ! et non pas juste la parser! 

 

Meme si vous pensez que le parser doit générer une Exception.

Exemple sur une question venue ce matin et utilisant la classe suivante : 

https://docs.oracle.com/javase/7/docs/api/java/text/DateFormat.html#parse(java.lang.String)

Et oui, le code suivant ne génère pas d’exception : 

 

import java.lang.String;
import java.text.*;
import java.util.Calendar;
import java.util.Date;

public class Main {

publicstaticvoid main(String[] args) {
DateFormat DFormat
= new SimpleDateFormat("dd/ mm/ yy");
try {
Calendar cal = Calendar.getInstance();

// Use of parse() method to parse
// Date From String
String dt = "10/ 27/ 16 <script>alert(1);</script>";
System.out.println("The unparsed"
+ " string is: " + dt);
// Parse string. if exception this is not a date
DFormat.parse(dt);

System.out.println ("Date parse and no exception, so use the string: " + dt);

} catch (ParseException excpt) {
excpt.printStackTrace();
}
}
}

Ce code produit : 

The unparsed string is: 10/ 27/ 16 <script>alert(1);</script>
Date parse and no exception, so use the string: 10/ 27/ 16 <script>alert(1);</script>

 

Toujours vérifier et/ou utiliser la valeur de retour d’une méthode si il y en a une ! 

#appsec #appsecfr #securecoding #java 

Formation Sécurité du Développement web en Java sur Niort

AppSecFR vous propose une formation de 3J sur le sujet de la Sécurité du Développement Web en Java

Cette formation aura lieu sur NIORT (79)  :

  • 26-27-28 Aout 2019 (pour bien recommencer a la rentrée 2019 !)
  • 7-8-9 Octobre 2019

Le contenu de la formation vous permettra de prendre en compte les problématiques de sécurité de Java et d’appliquer les bonnes pratiques dans le cadre d’exercices proche des technologies que vous pouvez utiliser.

Cette formation entre dans le cadre de l’obligation PCI-DSS 6.5 

A l’issu de la formation, le stagiaire recevra

  • Le certificat de formation AppSecFR(r) Secure DevWeb Java basic
  • Une feuille des contrôles de sécurité à effectuer sur son application Web.
  • Goodies 🙂

Le nombre de place est limité à 10 personnes par session.

Le prix : 1542 €HT pour 3j par stagiaire

Pour s’inscrire contactez AppSecFR en précisant la date, nous vous recontactons rapidement

Nous pouvons aussi réaliser la formation en intra-entreprise au besoin sur d’autres dates. Nous contacter pour plus d’informations

Joli Code …..

Trouvé il y a qq semaines lors d’un audit de code sur un projet contenant du JSP :

<%@ page import=" java.util.*,java.lang.*" %>
<%@ page import="java.io.* » %>
<%@ page import="java.net.* " %>
<%@ page import="java.xml.* " %>
<%@ page import="java.time.* " %>

J’aime bien ce type de développeur. J’auras peut etre une suggestion a leur faire comme celle la :

<%@ page import="java.* " %>

 

Comme ca, c’est plus simple 🙂

Retour sur la vulnérabilité Serialization de Java

Nous allons ici essayé de faire un retour sur cette vulnérabilité qui n’a pas fait surement assez de bruit. Elle a donné quand meme donné lui à un CVE de la part d’Oracle (CVE-2015-4852). Quand on connait Oracle et la sécurité, on peut se dire que cela doit être grave 🙂

Avant d’aborder la vulnérabilité en détail, il est nécessaire de se mettre bien au clair sur certains éléments.

Qu’est-ce que la sérialisation d’objet en Java ?

C’est un mécanisme introduit quasiment au début de Java (JDK 1.1) permettant d’écrire des données présentes en mémoire (un objet par exemple) dans un format de données binaires permettant alors de rendre persistants l’élément via un stockage disque, une transmission réseau ou autre.  Java, fourni un certain nombre d’outils permettant de sérialiser/désérialiser de manière transparente et indépendant du système :

  • L’interface Serializable; cette interface permet d’identifier les classes sérialisable. Il est nécessaire que votre classe implémenter cette interface ou hérite d’une classe sérialisable.
  • La classe ObjectOutputStream ; permet de sérialiser un objet. Elle dispose de la méthode writeObject() permettant d’effectuer cela.
  • La classe ObjectInputStream ; permet de désérialiser un objet. Elle dispose de la méthode readObject() pour cela.
  • Le mot clef transient permettant d’éviter de sérialisé un élément.
  • L’interface Externalizable permettant de gérer différemment  les  sérialisation et désérialisations.

Pour pouvoir correctement sérialiser un objet, il est nécessaire qu’il dispose de plusieurs éléments

  1. l’implémentation de l’interface Serializable
  2. Un numéro de série ;  le serialVersionUID qui permet lors d’une désérialisation que les classes sont concordantes. Il s’agit d’un static long final qui n’est pas obligatoire, java en calculant alors un automatiquement, mais il est recommandé de l’affecter soi-même (exemple : private static long serialVersionUID  = 42424242L)
Exemple :
public class User  implements Serializable {

private static final long serialVersionUID = 424242424242L;
private String nom, prenom ;
private String login;
transient String password;

public User(String nom, String prenom, String login, String password) {
this.nom = nom ;
this.prenom = prenom ;
this.login = login;
this.password = password;
}
}


 

public class Main  {
    static public void Main (String ...args) throws ClassNotFoundException  {
        File fichier = new File("tmp/test.ser");
        try {

ObjectOutputStream oos = new ObjectOutputStream(new FileOutputStream(fichier));
//Sérialisation
User oout = new User(« Ford », « Escord », « fescord », « fortytwo »);
oos.writeObject(oout);
oos.close();

ObjectInputStream ois = new ObjectInputStream(new FileInputStream(fichier));
// désérialization de l’objet
User oin = (User) ois.readObject();
System.out.println(oin);
ois.close();
} catch (IOException ioException) {
System.err.println(« IOException »);
}
}
}

 
Ici nous avons donc une classe qui va permettre d’écrire dans le fichier test.ser les données d’un utilisateur en dehors du champ password.
Si vous souhaitez effectuer une sérialisation différente de ce que propose Java, il faut donc implémenter l’interface Externalizable.  ou tout simplement  surcharger les méthodes writeObject() et readObject(). Cela permet alors de créer un fichier avec la représentation que vous souhaitez par exemple. 

La Sérialisation permet donc de :

  • Sauvegarder des objets/éléments Java
  • Echanger des objets entre JVM  (par des Streams…dont des NetworkStream)
  • Créer une copie intégrale d’un objet
  • Rentre persistents des objets dans des fichiers…

Revenons maintenant à notre vulnérabilité, maintenant que globalement nous pouvons comprendre à quoi sert la Serialisation en Java.

C’est quoi cette vulnérabilité de Sérialisation Java?

En Janvier 2015 a la conférence AppSec Californie Chris Frohoff et Gabriel Lawrence  présentent leur travaux et des outils autour d’une exploitation des mécanismes de serialisation et leurs utiliisation de manière malveillante.

Il faut attendre le 6 Novembre 2015 pour que Stephen Breen , via un article de Blog , informe qu’un certain nombre de bibliothèques Java sont chargées par défaut par les serveurs Applicatifs (WebSphere, Jboss, WebLogic, ….) et que parmi ces bibliothèques, une importante Apache Commons est vulnérable a des attaques par désérialisation. Je cite :

NewImage

Ce qu’il faut comprendre c’est que cette librairie est l’une des plus utilisées. En particulier quasiment tous les serveurs applicatifs la charge au démarrage. C’est une bilbiothèque très pratique car comportant énormément de classes intéressante (les commons.io, commons.lang, commons.log pour ne citer que les plus connues ).

Les travaux de Chris Frohoff et Gabriel Lawrence ayant montré comment il est simple d’executer une commande système depuis le CLASSPATH, il est alors simple de voir le potentiel impact de la vulnérabilité présente dans les Apache commons. En effet, si le serveur applicatif utilise cette derniere, et donc la charge au démarrage,il est potentiellement possible d’injecter une commande système via par exemple la classe Runtime.

Stephen Breen a démontré que via cette vulnérabilité certains serveurs pouvaient exécuter du code via différents protocoles (T3 ppour WebLogic, JMX pour JBOSS) .

Comment m’en protéger si je suis utilisateur d’un serveur Java?

C’est bien la chose la plus importante a avoir en tete. Il faut deja se souvenir de plusieurs choses si vous utilisez ces serveurs et bibliothèques (mais rien ne dis que d’autres bibliothèques Java standard ne seraient pas touchées….)

  1. Filtrez les ports pour ne laisser que les protocoles nécessaires, il est rare d’avoir besoin depuis Internet de laisser entrer du JMX, T3, …
  2. Gardez a jour vos applications ; suivre les listes des éditeurs et mettre les patchs correctement. La Fondation Apache a réagi très vite
  3. Gardez a jour vos bibliothèques (par exemple utilisez l’outil OWASP-DepencyCheck pour avoir une vue sur ces dernières)

Et si je développe du code ?

Dans le cas du développement de code, il existe une bonne pratique pour vos différentes classes a ajouter comme template de votre éditeur pour éviter des problèmes liés à la sérialisation. Il suffit de surcharger les méthodes writeObject() et readObject() et de leur faire remonter une exception dans le corps du code. Exemple  :

    private void writeObject(ObjectOutputStream out)  throws IOException
    {
        throw new NotSerializableException();
    }

private Object readObject(ObjectInputStream in) throws IOException,
ClassNotFoundException
{
throw new NotSerializableException();

}

et puis à suivre les bonnes pratiques de SecureCoding Java et de la cheat Sheet OWASP