Position du module "Système d'Information" dans la formation Licence Informatique

Le module "Système d'Information" est un module enseigné pour les étudiant en 2ème année Licence Informatique à travers le territoire national. Ce module est enseigné dans l'université pour plusieurs autres spécialités et depuis des dizaines d'années. Une bonne partie du cours n'est pas mise à jour et enseignée telle qu'elle l'était depuis plus de 20 ans. Par rapport aux nouvelles technologies et nouvelles approches (Cloud Computing, No SQL, reactive programming, etc..), ce module semble bien dépassé et expiré.

Mais, la réalité est bien le contraire. Le module "Système d'Information" n'a jamais était à propos d'une technologie et ne le sera jamais. Ce module vise à faire comprendre des notions abstraites, présentes dans toutes les organisations et nécessaires pour pouvoir comprendre les enjeux à faire face durant la conception d'un "Système d'Information". Comme la notion de variable qui existe depuis 60 ans dans les programmes d'enseignement, la notion "Système" doit être présentée comme elle l'était depuis toujours.

Malgré que le module est généralement doté d'une partie pratique attachée à une méthode ou approche particulière, cette dernière n'a jamais été son objectif. Ainsi, si nous donnons Merise (on l'utilise encore pour enseigner) comme un exemple d'application, c'est pour pouvoir donner des exemples sur les notions théoriques que l'étudiant doit saisir. L'objectif n'est jamais le MCD, MCT ou MOT.

L'importance de ces notions réside dans leur niveau d'abstraction très élevé. En effet, elles sont indépendantes de toute technologie, de toute approche et de toute forme d'organisation. Elles sont si abstraites qu'elles englobent toutes ces notions. Les notions abstraites données en "Système d'Information" définissent les positions de ces derniers éléments, leurs rôles, les exigences qu'ils doivent respecter et leur dimension fonctionnelle.

Sur le plan pratique, le module vise à introduire les étudiants à cette idée de reprendre une organisation, de comprendre son fonctionnement et de proposer une solution d'automatisation. Cette activité de modélisation doit être comprise, non pas dans le cadre de l'approche choisie comme champs d'application, mais dans son principe de base et sa philosophie générale.

Ainsi, ce module marque les frontières entre les spécialistes et les amateurs. Ceux sont ces notions qui permettent aux professionnels de choisir la bonne solution pour le bon problème. Et par bonne solution, je veux dire sur le plan technique, conceptuel et organisationnel. Ainsi, on ne trouvera jamais un professionnel qui construit une solution pour une grande organisation en utilisant une API JavaScript proposée depuis un mois juste parce que c'est la mode.

En terme de formation, ce module est lié à d'autres modules dont il représente une introduction. Le module Base de Données repose sur les notions acquises pour justifier la construction des applications autour des données centralisées dans des bases de données. Par la suite, le module Adminsitration des Bases de Données continuera sur la même voie et nécessitera la compréhension de la notion de charge et une imagination de la taille des données dans une organisation donnée. Le module Génie logiciel nécessite aussi la compréhension des notions du SI; comprendre les enjeux des ressources, des délais et de déploiement nécessitent la compréhension de la notion d'organisation et du système. Finalement, le module IHM nécessite la compréhension de la notion de scénario métier pour pouvoir définir les actions prévues par l'utilisateur et les lier aux données modelées.

Le Système d'Information est le niveau abstrait d'un ensemble de spécialités et d'approches. Il est indépendant de toute technologie et de toute approche. Mais, sa compréhension est nécessaire pour une meilleure utilisation de ces technologies et de ces approches dans le contexte professionnel.

[DEI] SQL Injection exemple

"La faille SQLi, abréviation de SQL Injection, soit injection SQL en français, est un groupe de méthodes d'exploitation de faille de sécurité d'une application interagissant avec une base de données. Elle permet d'injecter dans la requête SQL en cours un morceau de requête non prévu par le système et pouvant en compromettre la sécurité." (Wikipedia)

Pour démontrer cette attaque, il nous faut un système qui interagit avec une base de données. Ainsi, nous prennons la base de données simple suivants :

Create Database SQLInjection;

Create Table User (
    id char(100) Primary Key,
    password char(100) Not Null
);

Insert into User Values ('admin', 'admin');

Le code ci-dessus devrait fonctionner sur tous les SGBD-R (ou au moins la plus part). Nous créons, ainsi, une seule table qui sert à authenrifier les utilisateurs. L'objectif de l'attaque sera, dans ce cad, de réussir l'authentification sans avoir un id et un password valides.

L'application victime se compose de deux classes. La première classe garantir l'accès à la base de données. La méthode qui nous intéresse est la méthode "verifierUser()" qui retroune Vrai si l'authentification a réussi, c'est à dire, s'il existe au moins un utilisateur avec le id et le password saisis (le SGBD utilisé est MySQL) :

package bdd;

import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.PreparedStatement;
import java.sql.ResultSet;
import java.sql.SQLException;
import java.sql.Statement;

/**
 *
 * @author Tarek Boutefara <t_boutefara@esi.dz>
 */
public class AccesBDD {
    
    public static Connection connexion;
    
    public static Connection getConnexion() throws ClassNotFoundException, SQLException{
        if(connexion == null){
            Class.forName("com.mysql.jdbc.Driver");
            connexion = DriverManager.getConnection("jdbc:mysql://localhost/SQLInjection", "tarek", "");
        }
        return connexion;
    }
    
    public static boolean verifierUser(String user, String password) throws ClassNotFoundException, SQLException{
        String requete = "Select * from User Where id = '" + user + "' and password = '" + password + "';";
        System.out.println(requete);
        Statement statement = getConnexion().createStatement();
        ResultSet resultat = statement.executeQuery(requete);
        return resultat.next();
    }
    
}

La requête utilisé pour extraire l'utilisateur est une requête simple. Si les paramètres "user" et "password" ont les valeurs "admin" et "admin, la requête générée sera :

Select * from User Where id = 'admin' and password = 'admin';

La deuxième classe est une JFrame qui permet la saisie des deux valeurs à passer pour la méthode "verifierUSer()" citée ci-dessus. Elle affiche un message de confirmation en cas de réussite de l'authentification et un message d'erreur dans le cas contraire :

   private void btnLogInActionPerformed(ActionEvent evt) {                                         
        try {
            if(AccesBDD.verifierUser(txtUser.getText(), txtPassword.getText())){
                JOptionPane.showMessageDialog(this, "Login avec succès", "Succès", JOptionPane.INFORMATION_MESSAGE);
            }else{
                JOptionPane.showMessageDialog(this, "Login a échoué", "Echec", JOptionPane.ERROR_MESSAGE);
            }
        } catch (ClassNotFoundException ex) {
            ex.printStackTrace();
        } catch (SQLException ex) {
            ex.printStackTrace();
        }
    }              

La saisie des paramètres corrects

Le message au cas du succès

Saisie des paramètres incorrects

Message en cas d'échec

Jusqu'à maintenant, l'exécution semble normale parce que les valeur saisies ont été prévues par le développeur. LE problème se pose lorsqu'on commence à saisir non pas des valeurs simples mais des codes SQL. Par exemple, la saisie de la valeur suivante comme mot de passe :

' or '1' = '1

Permet de s'authentifier avec succès :

Pour comprendre la raison, il faut jeter un coup d'oeil sur la requête SQL générée après la saisie de cette valeur :

Select * from User Where id = '' and password = '' or '1' = '1';

Ainsi, al avleur saisie a permis de modifier le code de la requête et de changer sa signification.

Ce type d'attaque nécessite la vérification de toutes les données saisies comme il est possible d'utiliser des méthodes de connexion à la base plus sûres telles que l'utilisation de preparedStatement au lieu de Statement sous Java.

    public static boolean verifierUserSecurisee(String user, String password) throws ClassNotFoundException, SQLException{
        String requete = "Select * from User Where id = ? and password = ?;";
        PreparedStatement pstatement = getConnexion().prepareStatement(requete);
        pstatement.setString(1, user);
        pstatement.setString(2, password);
        ResultSet resultat = pstatement.executeQuery();
        return resultat.next();
    }

[DEI] XSS exemple

"Le cross-site scripting (abrégé XSS) est un type de faille de sécurité des sites web permettant d'injecter du contenu dans une page, provoquant ainsi des actions sur les navigateurs web visitant la page. Les possibilités des XSS sont très larges puisque l'attaquant peut utiliser tous les langages pris en charge par le navigateur (JavaScript, Java, Flash, etc.) et de nouvelles possibilités sont régulièrement découvertes notamment avec l'arrivée de nouvelles technologies comme HTML5." (Wikipedia)

Pour démontrer cette attaque, nous avons créé l'exemple le plus simple en utilisatant J2EE comme technologie côté serveur. L'application web Java est constituée de deux pages :

1. Une page HTML qui contient le formulaire qui permet la saisie des données non-vérifiée.
2. Une page JSP, la page cible qui affiche naïvement un contenu prevenant d'une autre page.

index.html

<html>
    <head>
        <title>Formulaire</title>
        <meta charset="UTF-8">
        <meta name="viewport" content="width=device-width, initial-scale=1.0">
    </head>
    <body>
        <h1>Exemple attaque XSS :</h1>
        <form action="welcome.jsp" method="post">
            <label>Login : </label>
            <input type="text" name="login" placeholder="Votre login..."/>
            <br />
            <input type="submit" value="Se connecter" />
        </form>
    </body>
</html>

welcome.jsp

<%@page contentType="text/html" pageEncoding="UTF-8"%>
<!DOCTYPE html>
<html>
    <head>
        <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
        <title>Page d'affichage</title>
    </head>
    <body>
        <h1>Exemple attaque XSS :</h1>
        Bienvenue <% out.print(request.getParameter("login")); %>
    </body>
</html>

Il est évident qu'une saisie "normale" (attendue par le développeur) ne causera aucun problème : l'utilisateur saisit son nom sur une page et reçoit un message de bienvenue sur une deuxième page (après authentification par exemple).

Le problème se pose lorsque l'utilisateur introduit un code exécutable. Ce code sera repris par la deuxième page et inséré comme un élément de la page. Sans un contrôle des données, le code exécutable, s'il est bien fait, sera considéré comme un élément ordinaire de la page et exécuté. Le code peut même ajouter des biliothèque de tracking ou bien récupérer des données (Cookies du site actuel) et les envoyer à d'autres serveurs.

A titre d'exemple, si la valeur donnée à l'information "login" dans l'exemple ci-dessus est :

<script language="javascript">(function(){alert("Hello");})();</script>

Le résultat obtenu est le suivant :

Le problème sera mieux compris si nous jetons un coup d'oeil sur le code source de la page :

Nous pouvons constater que le "login" saisi n'est plus une chaîne simple mais il est considéré comme une balise html valide. Etant de type script, la méthode contenue dans l'élément est exécutée et le message "Hello" est affiché.

Le problème peut être résolu par plusieurs méthode. L'idée est de modifier le code saisi pour qu'il ne soit plus exécutable.

[GOE] Survivre à la concurrence : l'industrie automobile en Grande Bretagne.

Malgré que le secteur en relation avec les automobiles est actif en Grande Bretagne, il pourrait être encore plus puissant si les managers ont su survivre à la concurrence.
En effet, ce secteur, qui emploie plus de 600 milles personnes et qui génère un chiffre d'affaire de plus de 65 Milliards d'Euro, produit généralement des moteurs et des véhicules utilitaires. La plus part des marques ont été soit mises en faillite ou bien achetées par des entreprises étrangères.
Ainsi, on a vu la Grande Bretagne passe de la 2ème position (après les Etats Unies) comme producteur des automobiles à la 12 ème place en moins de 20 ans.
Les conurrences qui pu remplacer la Grande Bretagne sont, notamment : l'Allemagne, la France, le Japon et la Chine. Des entreprises originaires de ces pays ont acquis la plus part des entreprises britaniques. A titre d'exemple, le groupe allemand BMW a acquis Mini et Rolls-Roys. Le groupe chioins SAIC detient actuellement l'entreprise britanique Rover.
Quelques voitures britaniques :

Jaguar e-Type

Aston Martin DB5

MG MGB

De l'autre côté, nous pouvons voir l'évolution des concurrents, à titre d'exemple la Chine, qui a passé de :

VW Santana chinoise

A :

Qiantu K50

[GOE] Les changements brusques dans l'environnement de l'entreprise, exemple d'actualité

L'inconvénient principal des deux écoles (classique) et (relation humaine) est l'absence de toute analyse de l'environnement de l'entreprise. L'école classique s'est concentrée sur l'aspect technique et sur la mise en oeuvre et la définition des fonctions de base de l'entreprise. L'école des relations humaines s'est concentrée sur la dimension humaine des employés. Les axiomes et les principes de ces deux écoles ne font aucune référence à l'environnement de l'entreprise.

Cet inconvénient a coûté cher à un grand nombre d'entreprises. En effet, avec l'arrivée de la concurrence et des changements technologiques, économiques et sociaux rapides et brusques, la grande majorité des entreprises n'arrivaient pas à survivre.

L'école managériale, actuellement suivie, qui repose sur une planification du changement et l'utilisation avancée des technologies de l'information et de la communications, a prouvé son efficacité dans des conditions très difficiles et dans des environnements très hostiles.

Le prince Walid ben Talal

Nous prenons à titre d'exemple, un fait très récent qui date le 04 Novembre 2017, le groupe saoudien "kingdom", propriété du prince Walid ben Talal, a connu un choque particulier avec l'arrestation de son propriétaire suite à des accusation de corruption. Et malgré que les investigations n'ont pas donné de résultats et qu'il s'agit au stade actuel des "accusations" et que le principe n'a pas été trouvé "coupable", les rumeurs et les analyses sur le marché ne laisse pas la place à une deuxième possibilité; ce qui représente un changement très brusque et une pression particulière imposée sur le groupe "kingdom".

C'est à ce stade que nous pouvons voir l'utilité d'une vision stratégique d'un côté et d'une séparation entre les deux acteurs : managers et actionnaires. Au cours de la journée du 05 Novembre 2017, les cours du groupe ont connu une chute libre dans la bourse saoudienne au début de la journée. Néanmoins, une amélioration remarquable a pu être constatée au fur et à mesure; cette amélioration ne peut être justifiée que par les efforts des managers encore sur le terrain malgré l'absence de l'actionnaire principal. Nous pouvons supposer avec une grande certitude qu'il s'agissait essentiellement d'un effort fourni pour assurer les autres actionnaires et les autres acteurs que le groupe "kingdom" peut continuer avec les mêmes performances.

La chute des cours du groupe "kingdom" et la récupération au cours de la journée.

Les cours du groupe en connu des pertes d'environ 7%, mais les dégâts pouvaient être plus graves.