Les entreprises ont dû mettre en place une nouvelle organisation pour poursuivre leur activité malgré la pandémie. Le télétravail a ainsi explosé depuis la crise sanitaire mondiale. Bien que cette transformation numérique leur ait permis de ne pas sombrer, les problèmes liés à la cybersécurité restent une préoccupation essentielle. Prévoir des solutions informatiques sécurisées est donc devenu une priorité.
Une augmentation des cyberattaques
Le télétravail a connu un essor important depuis le début de la crise sanitaire. La transformation numérique était donc incontournable pour de nombreuses entreprises, tous secteurs d’activité confondus.
Cependant, le travail à distance a favorisé la multiplication des cyberattaques en tout genre. Faute d’anticipation, les entreprises se sont retrouvées vulnérables face à des problèmes de sécurité informatique. La révolution du télétravail les oblige pourtant à envisager des solutions efficaces pour remédier à ce souci.
Diverses formes d’attaques menées par des hackers dans le but de s’emparer des données personnelles des utilisateurs se sont multipliées. Il existe différents types de menaces :
L’IOT ou Internet des objets, utilisé pour optimiser le contrôle de la maison à distance, a par exemple multiplié les risques de cybersécurité depuis la pandémie. En travaillant depuis chez lui, le salarié met les données de l’entreprise en danger. D’où la nécessité de recourir à une entreprise spécialisée comme www.landvart.com pour auditer la sécurité informatique.
Le phishing ou la récupération de données via des logiciels malveillants et l’intelligence artificielle a aussi pris de l’ampleur durant la crise sanitaire.
L’utilisation quotidienne des réseaux sociaux a davantage facilité le piratage des données confidentielles des employés. De plus, il a été plus facile pour les hackers d’exploiter ce canal en partageant des liens.
Renforcer la sécurité informatique : une priorité pour les entreprises
Bien que la situation commence à s’améliorer avec le retour au bureau en présentiel, le renforcement de la sécurité reste une priorité pour les entreprises. D’autant plus que le télétravail risque d’occuper une place de plus en plus importante dans l’avenir. Ainsi, de nouvelles stratégies doivent être mises en place pour sécuriser les différents appareils et services hébergés sur serveurs.
La migration des serveurs sur le cloud
La migration vers le cloud peut être un choix judicieux pour minimiser les risques de cybersécurité. Cela peut concerner les serveurs, les données, les applications, et même les emails et sauvegardes.
En plus de faciliter le télétravail, cette solution garantit une meilleure organisation, et surtout une sécurité plus poussée. Toutes les données de votre entreprise seront à l’abri de toute tentative de fraude. Tout le monde peut avoir accès aux informations à distance, à tout moment, et vous pouvez vous libérer des mises à jour et maintenance des serveurs.
Faire appel à une société de services informatiques
Pour mener à bien la migration vers le cloud, il n’y a rien de tel que le recours à une entreprise d’informatique spécialisée dans le domaine. Le basculement vers cette solution sécurisée peut s’avérer compliqué, d’où la nécessité de se faire accompagner. Avec un professionnel, vous pouvez bénéficier de conseils pratiques, et d’une offre sur mesure en fonction de vos besoins précis.
Pi-hole est un projet open-source prévu pour tourner sur un raspberry pi, qui permet de filtrer les requêtes DNS dans le but de bloquer les publicités et le tracking. L’idée est de faire ce filtrage au niveau du réseau afin de pouvoir bloquer aussi les publicités dans les applications et sur les navigateurs mobiles qui n’ont pas forcement d’Adblock.
Pour mon installation j’ai ressorti un vieux raspberry 1 b+ et j’ai utilisé l’installation recommandé sur le site:
curl -sSL https://install.pi-hole.net | bash
Avant de lancer la commande, pensez-bien à vérifier le script.
Par la suite j’ai laisser tout les paramètres à leurs valeurs par défaut.
Sur ma box j’ai fixé une IP fixe pour le raspberry (192.168.1.254).
Une fois l’installation terminé l’interface web est accessible à l’URL http://192.168.1.254/admin. A la fin de l’installation un mot de passe vous a été donné. Mais si vous l’avez perdu vous pouvez le réinitialiser via la commande:
pihole -a -p
Maintenant il ne reste plus qu’à utiliser notre nouveau serveur DNS en tant que DNS primaire.
Si comme moi vous avez une livebox, vous allez être heureux d’apprendre que vous ne pouvez pas/plus changer les DNSs au niveau de la box. J’ai donc coupé le wifi de la livebox et ajouté un routeur wifi qui lui va me servir de DHCP et qui va s’occuper de résoudre les requêtes DNS en passant par pi-hole.
Si vous ne souhaitez pas ajouter un routeur WIFI, et que ne vous ne pouvez pas modifier les DNS de votre box, il faudra modifier manuellement les DNS sur chaque PC, téléphone et tablette. (c’est vraiment pas idéal)
Après quelques heures d’utilisation j’ai constaté que 15% des resolutions DNS qui sont fait dans le cadre d’une navigation classique sont vers des sites de tracking ou de publicité. Je suis franchement surpris car je m’attendais à bien pire…
Il possible d’ajouter manuellement ou via un fichier accessible en HTTP des domaines à bloquer/autoriser.
En quelques minutes d’installation, grace à pi-hole, il est possible de limiter le tracking est la publicité pour l’intégralité de votre réseau local. Simple mais efficace.
Si on veux aller un peux plus loin dans le blocage ont peux ajouter des listes de noms de domaines maintenues par la communauté. Avec cette liste vous passerez à plus de 600 000 domaines de bloqués.
Pour les ajouter il faut se rendre dans Settings > Blocklists et il faut simplement coller la liste des listes de domaines tel quel dans le champs text et enregistrer.
Petit test de navigation sur mon téléphone avec et sans pi-hole:
Mole est une application en ligne de commande qui permet de simplifier la création de tunnels SSH.
Il est parfois utile de monter un tunnel pour accéder à un service qui n’est pas ouvert sur le WEB. Par exemple si votre serveur MYSQL, n’est accessible que depuis votre serveur web ou votre serveur de backup. Ou encore pour contourner un firewall qui bloquerait un port en particulier.
Sur cet exemple le serveur bleu ne peut pas accéder au port 80 (application web) du serveur rouge car un firewall le bloque. Mais le port 22 (ssh) est accessible. Il est donc possible de créer un tunnel qui forward le port 80 sur serveur rouge sur le port 8080 du serveur bleu. Une fois le tunnel mis en place il sera possible d’accéder à l’application web du serveur rouge via l’url: http://blue:8080.
Installation
Deux méthodes d’installation sont possibles. Via le script d’installation ou via homebrew pour les utilisateurs de mac.
Pour se connecter à un serveur mysql qui n’est pas ouvert sur le web nous allons ouvrir un tunnel entre le port 3306 local du serveur et le port 3307 de mon mac :
Je peux maintenant me connecter au serveur mysql du serveur sur le port 3307 de ma machine :
➜ mysql connect -h 127.0.0.1 -P 3307 -uxxxxxxx -p
Gestion des alias
Le dernier point qui est bien pratique si vous avez à jongler avec plusieurs serveurs c’est la gestion des alias. Il est possible d’enregister des alias pour les tunnels que l’on a fréquemment à créer.
Au travail nous avons pour politique de builder et de maintenir nos propres images docker. Mais pour un projet perso j’utilise des images docker publiques. Je m’efforce d’utiliser au maximum des images officielles mais certaines contributions de la communauté sont parfaites pour mes besoins. Le problème est de savoir avec certitude ce que contient un image. Une image téléchargée sur un hub est une boîte noire qu’il faut inspecter avant de l’utiliser.
Cas d’images corrompues
Il y a l’exemple de l’utilisateur docker123321 qui a diffusé 17 images contenant des backdoors sur dockerhub. Parmi les images il y a tomcat, mysql ou encore cron. Avec quasiment 5 millions de téléchargements docker123321 a réussi à miner plus de 500 Moneros en plus des portes d’entrées qu’il a créées sur le serveur.
Contenu d’une image docker
Une image docker est une succession de couches (layers) qui contiennent une liste de modifications du système de fichiers. On peut faire une analogie avec GIT où chaque layer serait un commit. Au moment de la création d’un container un layer est ajouté au-dessus de ceux de l’image. Mis à part ce layer « applicatif » les layers sont en read only.
Dive est un programme écrit en Go qui va vous permettre d’en savoir plus sur une image avant de l’utiliser. Il ne va pas permettre de s’assurer à 100% que l’image n’est pas corrompue mais il va pouvoir nous donner des information précieuses.
Pour l’installation je vous laisse vous référer au readme du projet.
Voici un exemple d’utilisation sur l’image jonbaldie/varnish que j’utilise pour un projet perso.
➜ dive jonbaldie/varnish
Sur l’image on a 5 layers :
L’image de base
L’ajout d’un script d’installation (/install.sh)
Le résultat de l’execution du script d’install
L’ajout du script de boot (/start.sh)
Le chmod du script de boot
Vérifier les scripts présents dans l’image
Sur la base des informations données par Dive, il ne nous reste plus qu’à vérifier, si possible, le contenu des fichiers install.sh et start.sh
Pour un fichier toujours présent dans le dernier layer
Le fichier start.sh n’est pas supprimé après l’installation. Il est donc simple de le consulter:
➜ docker run --rm -ti jonbaldie/varnish cat /start.sh
Pour un fichier non présent dans le dernier layer
Pour le fichier install.sh il ne va malheureusement pas être possible de l’afficher car il est supprimé pendant le build. Le docker history de l’image ne me donne pas d’image Id correspondant à ce layer car je n’ai pas buildé l’image sur ma machine.
Docker history sur jonbaldie/varnish
Il n’est pas possible de lancer un container sur une image qui contient le install.sh. Et c’est bien là le problème ! C’est une boîte noire.
Pour arriver à consulter ce fichier il va falloir exporter l’image et naviguer dans les layers « à la main ».
Pour voir le fichier on va récupérer le tar id du layer qui nous intéresse via Dive :
On sait donc maintenant qu’il faut regarder le contenu du tar « c06fe384a155fd3501bdb5689a4d79a18c80a63243038184f457793490b7ddde » pour trouver mon fichier install.sh.
Récupérer un fichier dans un layer docker
Vérifier l’image de base
Dans notre cas l’image est construite à partir d’une debian officielle. Mais comment s’en assurer ? Est-ce que cette debian est à jour ?
Dans un premier temps on va chercher la version de debian installée :
➜ varnish docker run --rm jonbaldie/varnish cat /etc/os-release
Trouver la version de debian utilisée dans une image docker
Malheureusement je ne sais pas comment vérifier que cette debian est bien une version officielle. Je ne peux pas non plus m’assurer que les mises à jour de sécurité sont faites.
Le seul indicateur de qualité à ce niveau est de regarder les builds. Cette image est buildée automatiquement sur la Docker Cloud’s infrastructure. Ce point est primordial dans le choix d’une image non officielle car cela nous donne l’assurance que le docker file affiché est bien celui qui est utilisé pour le build.
Sur le dernier build par exemple nous avons plusieurs informations à disposition :
Building in Docker Cloud's infrastructure...
Cloning into '.'...
KernelVersion: 4.4.0-93-generic
Arch: amd64
BuildTime: 2017-08-17T22:50:04.828747906+00:00
ApiVersion: 1.30
Version: 17.06.1-ce
MinAPIVersion: 1.12
GitCommit: 874a737
Os: linux
GoVersion: go1.8.3
Starting build of index.docker.io/jonbaldie/varnish:latest...
Step 1/9 : FROM debian
---> 874e27b628fd
Step 2/9 : MAINTAINER Jonathan Baldie "[email protected]"
---> Running in 3691027bb23a
---> 6e1fd6e2af21
Removing intermediate container 3691027bb23a
Step 3/9 : ADD install.sh install.sh
---> 2d9d517255c6
Removing intermediate container 1882f5bc4a22
Step 4/9 : RUN chmod +x install.sh && sh ./install.sh && rm install.sh
---> Running in 77dd464fc5be
Ign:1 http://deb.debian.org/debian stretch InRelease
//...
Get:8 http://security.debian.org stretch/updates/main amd64 Packages [227 kB]
Fetched 10.0 MB in 4s (2119 kB/s)
Reading package lists...
Reading package lists...
Building dependency tree...
Reading state information...
The following additional packages will be installed:
binutils cpp cpp-6 gcc gcc-6 libasan3 libatomic1 libbsd0 libc-dev-bin
libc6-dev libcc1-0 libcilkrts5 libedit2 libgcc-6-dev libgmp10 libgomp1
libgpm2 libisl15 libitm1 libjemalloc1 liblsan0 libmpc3 libmpfr4 libmpx2
libncurses5 libquadmath0 libtsan0 libubsan0 libvarnishapi1 linux-libc-dev
manpages manpages-dev
Suggested packages:
binutils-doc cpp-doc gcc-6-locales gcc-multilib make autoconf automake
libtool flex bison gdb gcc-doc gcc-6-multilib gcc-6-doc libgcc1-dbg
libgomp1-dbg libitm1-dbg libatomic1-dbg libasan3-dbg liblsan0-dbg
libtsan0-dbg libubsan0-dbg libcilkrts5-dbg libmpx2-dbg libquadmath0-dbg
glibc-doc gpm man-browser varnish-doc
The following NEW packages will be installed:
binutils cpp cpp-6 gcc gcc-6 libasan3 libatomic1 libbsd0 libc-dev-bin
libc6-dev libcc1-0 libcilkrts5 libedit2 libgcc-6-dev libgmp10 libgomp1
libgpm2 libisl15 libitm1 libjemalloc1 liblsan0 libmpc3 libmpfr4 libmpx2
libncurses5 libquadmath0 libtsan0 libubsan0 libvarnishapi1 linux-libc-dev
manpages manpages-dev varnish
0 upgraded, 33 newly installed, 0 to remove and 1 not upgraded.
Need to get 30.5 MB of archives.
After this operation, 123 MB of additional disk space will be used.
Get:1 http://deb.debian.org/debian stretch/main amd64 libbsd0 amd64 0.8.3-1 [83.0 kB]
//...
Get:33 http://deb.debian.org/debian stretch/main amd64 varnish amd64 5.0.0-7+deb9u1 [690 kB]
[91mdebconf: delaying package configuration, since apt-utils is not installed
[0m
Fetched 30.5 MB in 1s (18.9 MB/s)
Selecting previously unselected package libbsd0:amd64.
Preparing to unpack .../00-libbsd0_0.8.3-1_amd64.deb ...
//...
Setting up varnish (5.0.0-7+deb9u1) ...
Processing triggers for libc-bin (2.24-11+deb9u1) ...
vcl 4.0;
backend default {
.host = "127.0.0.1";
.port = "8080";
}
---> 0953378c3b8d
Removing intermediate container 77dd464fc5be
Step 5/9 : VOLUME /var/lib/varnish /etc/varnish
---> Running in c56c31df17fb
---> e7f1ae57b0f0
Removing intermediate container c56c31df17fb
Step 6/9 : EXPOSE 80
---> Running in e1f015e6366e
---> 6000a2d9d149
Removing intermediate container e1f015e6366e
Step 7/9 : ADD start.sh /start.sh
---> 085cec1148a7
Removing intermediate container 73e8ab753261
Step 8/9 : RUN chmod +x /start.sh
---> Running in 8ab33da3607a
---> 06f67d6546ac
Removing intermediate container 8ab33da3607a
Step 9/9 : CMD /start.sh
---> Running in 3910129787df
---> afa9f74c8d64
Removing intermediate container 3910129787df
Successfully built afa9f74c8d64
Successfully tagged jonbaldie/varnish:latest
Pushing index.docker.io/jonbaldie/varnish:latest...
Done!
Build finished
Première information, l’image est bien construite à partir de l’image debian officielle comme on peut le voir à la step 1: « Step 1/9 : FROM debian ».
Seconde information, l’image a été buildée le 17 Août 2017. Toutes les failles détectées depuis cette date sur varnish et debian stretch ne sont donc pas patchées.
Pour les images qui ne sont pas buildées automatiquement sur la plateforme je ne sais pas si c’est possible de vérifier l’intégrité de l’image de base. J’ai tenté plusieurs approches mais comme l’image utilise une « latest » et qu’elle a été remplacée par une nouvelle version je ne vois pas comment faire pour retrouver mon layer. Si vous avez une solution, je suis preneur.
Builder ses propres images
La solution qui présente le moins de risques est de builder soi-même ses images à partir des Dockerfiles mis à disposition par les contributeurs. De cette manière on peut faire une revue complète du code et des dépendances. En buildant moi-même mon image je pourrais avoir une version plus à jour de debian et de varnish.
Builder une image docker depuis les sources github
Conclusion
Il faut absolument se méfier des images mises à disposition sur le Dockerhub. Avant d’utiliser une image on doit se poser au minimum les questions suivantes :
Est-ce que l’image est officielle ou buildée automatiquement ?
Si non, est-ce que les sources sont disponibles ?
Si oui, est-ce que le dockerfile présenté est vraiment celui qui a servi à builder l’image ?
De quand date la dernière build ?
Au moindre doute il est préférable de builder sa propre version de l’image ou d’en utiliser une autre.
Le tuto fonctionne aussi sous Ubuntu 12.04 (oui c’est article qui date)
Le pare-feu « Shoreline Firewall », plus communément appelé « Shorewall« , est un outil qui permet de configurer plus facilement Netfilter (IpTable).
Shorewall est un outil qui permet de configurer Netfilter, son travail est fini.
L’avantage de Shorewall est qu’il est très flexible, une fois que l’on a compris la syntaxe.
Si vous avez d’autres firewalls il faut les désinstaller avant de commencer (ex: firestarter)
Installation de shorewall
Maintenant que les fichiers de configuration de base sont placés aux bons endroits nous allons pouvoir commencer à configurer Shorewall selon nos besoins.Par défaut les connexions entrantes sont refusées mais les connexions sortantes sont autorisées. Selon vos besoins vous pouvez changer la politique en éditant le fichier `/etc/shorewall/policy`. Dans la suite de l’article on partira du principe que la politique utilisée est la politique par défaut.
Mise en place des règles du firewall
Ouvrir le fichier qui contient les règles:
On a deux zones le « net » et le « $FW » (firewall).
Trois actions:
ACCEPT = accepter
REJECT = refuser
DROP = ignorer (préferez-le à reject)
Voici un exemple de fichier de configuration:
Avant de continuer pensez à vérifier que vous avez bien ajouté une règle pour autoriser votre connexion SSH. Par défaut c’est le port 22 mais il a pu être changé. Vérifiez que Port est bien à 22 dans : `etc/ssh/sshd_config`. Si ce n’est pas le cas il faudra modifier la règle correspondant au SSH
Maintenant que nous avons correctement configuré la bête reste à lui dire qu’elle peut être lancée.
Mettre la variable startup à 1 au lieu de 0.
Lancement de Shorewall
Allez il est temps de le lancer:
La sortie devrait plus ou moins ressembler à ça :
Si ce n’est pas le cas et qu’une erreur apparait c’est que vous avez un problème de configuration.
Hacker Target est un site Internet qui vous propose de tester les vulnérabilités de votre application web. Le site vous propose plusieurs types de tests selon votre site Internet.
Voici la liste complète des tests proposés gratuitement par le site (limité à 4/jours) :
les injections SQL
les CMS Drupal, Joomla et WordPress
les ports de votre serveur
les vulnérabilités de vos services
les problèmes de configuration ou de scripts
faire du fingerprint (déterminer les versions de vos librairies et logiciels)
en savoir plus sur votre domaine par le biais de whois par exemples
obtenir des infos sur vos CMS, fameworks, serveur, emplacement géographique…Etc
Nous allons ici détailler le test concernant WordPress car c’est celui que je viens de réaliser sur localhost:8080.
Voici la liste des tests :
WordPress Version Check
Site Reputation from Google, Norton and MyWot
Default admin account enabled
Directory Indexing on plugins
htaccess readable
robots.txt present
Sites Externally linked from main page (reputation checks)
WordPress Plugins that are detected passively and versions against latest versions.
Javascript linked
iframes present
internal site links
Hosting Reputation and Geolocation information
IP address sharing and reputation of sites sharing the IP address
Voici par exemple le type de conseils que l’on peut recevoir :
The WordPress administration login page is at the default location http://YOUR-WEBSITE/wp-admin/
This is not a critical risk however it should be understood that brute force attacks against WordPress login accounts including the admin account are not difficult. A strong password on the admin accounts is vital. It is recommended to rename the default admin account to a non-generic name.
Sinon, le rapport contient aussi la liste des liens externes de votre site afin de vérifier que personne n’a réussi à insérer des URLs vers des sites sans rapport. Vous aurez aussi en fin de rapport la liste des sites Internet qui sont hébergés sous la même IP, ainsi que leurs MyWOT Reputation et leur résultat au Google Safe Browse.
Vous l’aurez compris, cet outil peut vous donner de mauvaises surprises s’il tombe entre de mauvaises mains.
L’actualité étant chargée niveau hack, il est temps de sortir un petit article présentant différentes méthodes de sécurisation d’une application PHP. Je vais donc brièvement vous présenter différentes librairies ou classes PHP orientées sécurité.
PHPIDS Un monitoring complet des actions de l’utilisateur avec évaluation de la dangerosité de chaque requête, et de la session. L’outil indispensable pour détecter les recherches de failles.
Input filter Cette librairie permet de filtrer les tableaux $_GET, $_POST, $_REQUEST pour y detecter le PHP, JavaScript et HTML.
Anti csrf Permet d’ajouter un token dans ses formulaires afin de ne pas se les faire détourner. Le but étant que chaque formulaire ne soit soumis qu’une seule fois.
L’utilisation des librairies précédentes est un complément mais elles ne constituent pas une sécurité optimale à elles seules.
Voici donc une liste de bonnes pratiques niveau sécurité :
Ne jamais insérer des données dans une requête SQL sans un minimum de traitement. ( mysql_real_escape_string ou mieux PDO::prepare() et PDOStatment::bindValue() )
Ne jamais faire passer en paramètre une page à inclure exemple :
include $_GET[« ma_page »];
préférez une solution du type :
switch($_GET[« ma_page »]){
case « home » :
include « home.php »;
break;
case « forum » :
include « forum.php »;
break;
default :
inclue « error.php »
break;
}
Avoir un fichier index.html dans chaque dossier du projet, contenant
<html>
<head></head>
<body>
<h1>Accés interdit</h1>
</body>
</html>
Sécuriser ses session_start contre le vol de session.
$ip = !empty( $_SERVER[‘HTTP_X_FORWARDED_FOR’] ) ? $_SERVER[‘HTTP_X_FORWARDED_FOR’] : $_SERVER[‘REMOTE_ADDR’];
$securite = $ip.’_’.$_SERVER[‘HTTP_USER_AGENT’];
if(empty($_SESSION))
{
session_start();
$_SESSION[‘securite’] = $securite;
}
elseif($_SESSION[‘securite’] != $securite)
{
session_regenerate_id();
$_SESSION = array();
}
Voici donc une technique qui permet simplement de tester si une session est bien utilisée par le même navigateur sur la même machine.
Crypter les données sensibles de votre base (email,pseudo par exemple ). J’ai mis au point cette classe : Crypage.
Elle n’est certes pas extrêmement puissante mais elle permet de se protéger contre une injection SQL. Pensez bien sûr à changer la clef 😛 .
Le cryptage des mots de passe est une base de la sécurité. Pour cela utilisez une fonction comme celle-ci :
protected function crypteMotPasse($mot){
$salt = « !123 GRAIN DE SEL# »;
return sha1(strrev(ucfirst($mot).$salt));
}
Ceci est une idée le but est d’éviter que les mots de passe soient facilement lisibles en cas de piratage de notre base de données. Tout en sachant que des rainbow table existent pour inverser un md5 ou un sha1. Vous pouvez aussi définir un salt par user. Pour cela, au moment de la création du compte, vous générez une chaîne de caractères le plus aléatoirement possible, que vous stockez dans votre table user. Pour la connexion de l’utilisateur, il faudra dans un premier temps aller chercher le salt dans la base. Puis utilisez la fonction ci-dessus comme suit :
protected function crypteMotPasse($mot,$saltuser){
$salt = « !123 SALT FIXE# ».$saltuser;
return sha1(strrev(ucfirst($mot).$salt));
}
Comme le rappelle Simon dans son commentaire :
En effet, l’attaquant, pour obtenir l’ensemble des données de la base doit : – avec la fonction crypteMotPasse (salt à l’intérieur de la fonction) : regénérer une rainbow table – avec une fonction qui prend un salt différent par utilisateur : regénérer autant de rainbow table que d’utilisateurs
Empêcher un accès direct à vos fichiers PHP. Dans votre/vos fichier(s) d’entrée(s) (index.php par exemple) faites un :
define(« _BASE_URL »,TRUE);
Puis commencez tous vos autres fichiers PHP par :
<?php
if(!defined(‘_BASE_URL’)) die(« Erreur, la page est indisponible »);
Ajoutez la ligne suivante dans votre/vos fichier(s) d’entrée(s) afin d’activer les logs d’erreur PHP. Ceci est très utile pour débugger votre application lors de la phase de développement. Il faut cepandant penser à enlever cette ligne au moment de la mise en production.
<?php
error_reporting(E_ALL);
?>
Ne stockez que le minimum vital dans les cookies (voire rien si possible), réduisez la durée de vie de vos cookies, et cryptez les données qui sont dedans.
Pour les utilisateurs de CodeIgniter, activez le stockage de la session en base de données. Documentation allez à « Saving Session Data to a Database »
