Qu'est ce que l'eJPT ? Quels sont les avantages et les inconvénients de cette certification ? Comment se passe l'examen ? Est-ce que le cours PTS est suffisant ?
J'ai passé la certification eJPT il y a maintenant un an, et je voulais faire un retour d'expérience de l'avant certification, l'examen mais aussi l'après certification.
L'eJPT (eLearnSecurity Junior Penetration Tester) est une certification de sécurité informatique offensive (penetration testing => pentest).
Elle entièrement basée sur de la pratique (c'est pas un QCM reposant sur des connaissances), de niveau débutant. Il n'y a pas de rapport à écrire et à fournir comme les examens avancés (eCPPT ou OSCP par exemple). Il n'est pas non plus limité au niveau des outils, on peut utiliser tout ce que l'on veut (Metaploit ou SQLmap).
Le niveau d'anglais demandé n'est pas compliqué, donc si on se débrouille avec l'anglais technique c'est suffisant.
La certification est proposé par eLearnSecurity qui est un organisme de formation qui est de plus en plus réputé. Ils sont sérieux et réactifs.
Le cours est proposé par INE (plateforme de formation en ligne), il s'appelle PTS (Penetration Testing Student) et il couvre plusieurs sujets de manière basique :
Il s'agit d'une bonne base pour commencer et comprendre la sécurité offensive (pentest).
La sécurité informatique m'intéresse depuis aussi longtemps que le développement web et je m'éclate pas mal sur les plateformes type TryHackMe et Root-me.
Mais au quotidien, quand je remonte des soucis de sécurité à des clients, je n'ai souvent aucune crédibilité face au responsable sécurité.
Donc je voulais passer une certification qui atteste que j'ai des bases et que ce que je dis ce n'est pas pas toujours des bêtises 😛.
Je pense que lorsqu'on est développeur, il faut un minimum de connaissances sur les failles qu'on peut introduire (injection SQL, XSS, etc...).
Pour un développeur d'application système ce sera plutôt Heap overflow et Stack overflow par exemple.
Ça peut être généralisé à de nombreuses professions informatiques qui conçoivent et mettent en place des solutions accessible à sur un réseau (internet ou intranet).
Je but étant d'avoir des bases pour ne pas introduire de problèmes de sécurité, ou en tout cas en limiter le nombres.
Typiquement les mots de passe en dur dans le code, c'est courant, et facile à éviter.
L'eJPT a l'avantage d'être très général, simple et accessible pour une personne qui n'a jamais fait de sécurité informatique ou pentest.
Il couvre les failles web et les failles réseaux et donne les outils de bases pour analyser, exploiter et...
Comment modifier des messages de commit non poussés ? Comment modifier des messages de commit poussés ?
Vous avez commité un (ou plusieurs) fichier mais vous voulez modifier le message du commit ?
Si le commit n'a pas été push, il suffit d'utiliser l'option "amend" de la commande commit :
$ git commit --amend
Votre éditeur de texte (Vi, ou Nano suivant votre git config) s'ouvrira pour vous permettre d'éditer le message associé au dernier commit.
Si vous souhaitez modifier le message en une ligne de commande, c'est possible :
$ git commit --amend -m "Mon nouveau message de commit"
Assurez vous que vous n'avez pas de modifications en cours dans votre dossier. Si les modifications sont staged elles seront commités avec.
Si vous avez déjà push le commit, il utiliser l'option amend comme précédement et forcer le git push :
$ git commit --amend -m "Mon nouveau message de commit"
$ git push -f
L'option -f
de git push, va forcer le push et donc réécrire l'historique sur la branche distante. Si vous avez des commits sur la branche distante que vous n'avez pas récupéré en local, ils seront écrasé !
Si vous voulez modifier le message de commit d'un ou plusieurs autre commit, on peut utiliser le git rebase
:
$ git rebase -i HEAD~5
On va pouvoir éditer les 5 derniers commits. Vous pouvez remplace le chiffre 5
dans la commande pour en modifier plus ou moins.
L'éditeur du rebase s'ouvrira pour vous proposer d'éditer les commits.
Modifiez les messages que vous souhaitez et change pick
par reword
au début des lignes modifiées :
reword 05c739aa7 fix: message modifié numéro 1
reword 1705379c0 fix: message modifié numéro 2
pick 9f474ea66 fix: message non modifié
pick 788a5a1f0 chore: message non modifié
pick 8923e670f fix: message non modifié
Sauvegardez les changements et fermez l'éditeur. Vous pouvez faire un git log pour vous assez que les messages sont ceux désirés.
Et enfin, il faudra push -f pour réécrire l'historique distant :
$ git push -f
Vous pouvez aussi choisir de supprimer un commit. Je détaille comment le faire ici Supprimer un commit local ou distant
Comment supprimer un commit local avec Git ? Comment supprimer un commit distant avec Git ? Comment supprimer un commit push avec Git ?
Vous avez commité un (ou plusieurs) fichier par erreur ? Vous voulez supprimer ce commit ?
La commande simple est :
$ git reset HEAD~
Le sélecteur de révision HEAD~
fait référence au dernier commit.
Les modifications ne seront pas supprimées.
Vous pouvez poursuivre les modifications sur vos fichiers et si vous souhaitez les commiter avec le même message de commit que celui supprimé, c'est possible :
$ git add.
$ git commit -c ORIG_HEAD
Ce que fait git, c'est qu'au moment du reset, il copie hash du HEAD dans un fichier .git/ORIG_HEAD
. Donc en invoquand l'option -c ORIG_HEAD
, git est capable de récupérer le message de l'ancien commit. Il ouvre l'éditeur pour éditeur l'ancien message de commit.
Si vous voulez commiter avec l'ancien message sans l'éditeur, vous pouvez utiliser l'option -C
.
Pour supprimer un commit distant, c'est la même chose mais avec un push -f pour réécrire l'historique :
$ git reset HEAD~
$ git push -f
# ou mieux
$ git push --force-with-lease
L'option --force-with-lease
permet d'éviter de réécrire l'historique si une autre personne a fait un commit. Je préfère largement utiliser cette option pour éviter les surprises.
Nous pouvons aller un peu plus loin en modifiant les modes de git reset.
On est jamais bien sûr si nos modifications vont être supprimées, unstage
ou pas.
Voici donc un rappel sur les modes principaux :
unstage
(supprimé de l'index) et signale ce qui n'a pas été mis à jour. staging
(dans l'index). Le pointeur HEAD est déplacé (comme le font tous les modes). Je rappelle quel est la différence entre la copie de travail, l'index (staging), le dépôt local, le dépôt distant dans mon article sur Quelle est la différence entre git reset et git rm --cached
Vous avez déja rencontré cette erreur sur MacOs ? Ça vous bloque pour les déploiements Capistrano ?
Capistrano est un outils qui permet d'automatiser les déploiements.
Il se connecte en SSH au serveur spécifier et effectue les actions de déploiement.
Par exemple, il permet d'effectuer la liste d'action nécessaire comme lancer les migrations Doctrine, vider le cache, régénérer les fichiers de styles et les scripts optimisés, etc...
Bref c'est super pratique et il est aujourd'hui énormement utilisé dans la communauté PHP (Symfony, Zend, ...).
Il est codé en Ruby et utilise net-ssh
pour se connecter aux serveur en SSH.
Il a donc besoin que les clés publiques SSH soient enregistré dans l'agent d'authentification du système.
Sur MacOs, par défaut, les clés sont enregistrés que pour la session en cours, et c'est ça qui pose problème.
Cette erreur est commune, mais il y a des moyens simples de la résoudre.
Voici l'erreur complète :
NotImplementedError: OpenSSH keys only supported if ED25519 is available
net-ssh requires the following gems for ed25519 support:
* ed25519 (>= 1.2, < 2.0)
* bcrypt_pbkdf (>= 1.0, < 2.0)
See https://github.com/net-ssh/net-ssh/issues/565 for more information
Gem::LoadError : "Could not find 'ed25519' (~> 1.2) among 32 total gem(s)
Checked in 'GEM_PATH=/[...]/.gem/ruby/2.3.0:/Library/Ruby/Gems/2.3.0:/System/Library/Frameworks/Ruby.framework/Versions/2.3/usr/lib/ruby/gems/2.3.0', execute `gem env` for more information"
Tasks: TOP => deploy:check => git:check => git:wrapper
(See full trace by running task with --trace)
The deploy has failed with an error: OpenSSH keys only supported if ED25519 is available
net-ssh requires the following gems for ed25519 support:
* ed25519 (>= 1.2, < 2.0)
* bcrypt_pbkdf (>= 1.0, < 2.0)
See https://github.com/net-ssh/net-ssh/issues/565 for more information
Gem::LoadError : "Could not find 'ed25519' (~> 1.2) among 32 total gem(s)
Checked in 'GEM_PATH=/[...]/.gem/ruby/2.3.0:/Library/Ruby/Gems/2.3.0:/System/Library/Frameworks/Ruby.framework/Versions/2.3/usr/lib/ruby/gems/2.3.0', execute `gem env` for more information"
La solution la plus simple, c'est qu'à chaque démarrage du Mac, il faut ajouter la clé public à l'agent d'authentification :
$ ssh-add [path de la clé]
Pour vérifié que la clé a bien été ajouté :
$ ssh-add -l
Il est possible de mettre ça dans le fichier .bashrc
ou .bash_profile
pour que ce soit lancé à chaque démarrage.
Mais ce n'est pas la meilleure solution.
Ça me permet de présenter quelque commande, c'est toujours bien de les connaître ;).
Cette solution est de loin la meilleure et la plus générique :
Créez le fichier ~/.ssh/config
pour ajouter le contenu qui suit :
Host *
UseKeychain yes
AddKeysToAgent yes
Ce fichier n'ajoute pas directement les clés dans l'agent d'authentification. Il le fait une fois qu'on demande à utiliser les clés.
C'est à dire quand nous on se connecte en SSH par exemple.
C'est pour ça que la commande ssh-add -l
retourne rien. Par contre après un appel SSH, elle retournera bien la clé utilisé.
Par contre vous devrez saisir à nouveau votre mot de passe la première fois pour la session en cours.
À chaque reboot faudra recommencer.
Comment supprimer une branche locale avec Git ? Comment supprimer une branche distante avec Git ? Comment supprimer un tag local via Git ? Comment supprimer une tag distant via Git?
Vous voulez faire une peu de nettoyage dans votre depôt Git ? Il y a des branches ou des tags qui ne sont plus utilisés ? Rien de plus simple, il suffit de les supprimer.
Il y a deux commandes similaires :
$ git branch -d [nom-de-ma-branche]
$ git branch -D [nom-de-ma-branche]
Les deux options renseignés sont assez facile à deviner :
-d
est l'abbréviation de --delete
qui indique de supprimer la branche-D
est l'abbréviation de --delete --force
qui permet la suppression peut importe si elle a été mergé ou pasLa deuxième commande nous servira beaucoup plus souvent.
Pour supprimer une branche distante, c'est un peu différent :
$ git push [origin] --delete [nom-de-ma-branche]
Le paramètre [origin]
étant le nom de votre dépot distant.
Maintenant que nous avons vue comment supprimer une branche locale ou distante, on peut s'attaquer aux tags !
En effet, ce qui est bien c'est que pour supprimer un tag, c'est pareil ( ou presque ).
Voici la version locale :
$ git tag -d [nom-de-mon-tag]
L'option --force
ne sera beaucoup moins utile dans le cas du tag.
Pour la version à distante :
$ git push [origin] --delete [nom-de-mon-tag]
Non non il n'y a pas de bug, Git est assez intelligent pour différencier les tags des branches.
Mais il vaut mieux éviter de donner le même nom à une branche et à un tag...
Besoin d'un LAMP, WAMP ou MAMP pour un petit projet ?
Vous n'avez pas envie de vous prendre la tête à installer toute la stack sur votre machine ?
Vous voulez que cette stack soit lancée en une commande ? C'est possible !
Pour un petit projet PHP, je ne voulais pas installer toute la stack Apache, PHP, MySQL, ni lancer Vagrant.
Je me suis dis qu'en utilisant Docker ça devait être possible.
Et surtout, quelqu'un y a surement pensé avant moi et c'est disponible.
Pour ceux qui ne sont pas à l'aise avec les termes LAMP, WAMP, MAMP ou même XAMPP c'est pas compliqué !
La première lettre représente le système d'exploitation :
Le reste des lettres signifient :
Grosso modo, c'est la stack de base pour installer un site web PHP.
L'idée c'est d'utiliser Docker pour conteneuriser tout ces outils et pas avoir à les installer.
Tu nous parle de faire ça sans installation, mais il faut quand même Docker ?
He bien oui. Il faut bien partir de quelque part 😉 !
Du coup j'utilise le projet de mattrayner
sur Docker Hub.
Avec une seule commande il est possible de lancer un projet PHP simple.
Si vous avez besoin de modifier le VHost, ça demande plus de configuration.
Mais autant partir sur un fichier docker-compose traditionnel !
Placez vous dans votre répertoire de projet et lancez la commande :
$ docker run -p "80:80" -v ${PWD}:/app mattrayner/lamp:latest-1804
Rendez-vous dans votre navigateur et entrez l'IP Docker (dépend de votre configuration).
Et voilà !
Pour information, le latest-1804
à la fin de la commande est la version LTS d'Ubuntu à utiliser.
Les trois principales valeurs sont :
# Version 18.04
docker run -p "80:80" -v ${PWD}:/app mattrayner/lamp:latest-1804
# Version 16.04
docker run -p "80:80" -v ${PWD}:/app mattrayner/lamp:latest-1604
# Version 14.04
docker run -p "80:80" -v ${PWD}:/app mattrayner/lamp:latest-1404
Le gros avantage, c'est que si vous avez Docker de déjà installé, ça va très vite !
Et en prime PHPMyAdmin est déjà installé accessible sur /phpmyadmin
Si vous voulez aller plus loin avec cette image, il est possible de passer par un Dockerfile.
Vous pouvez par exemple installer Redis, modifier les configurations Apache PHP ou MySQL, etc...
Voici un exemple de base :
FROM mattrayner/lamp:latest-1804
# Vos propres commandes ici
CMD ["/run.sh"]
J'ai pas eu besoin de créer le Dockerfile, donc je vous laisse tester. Si jamais je dois passer par là je mettrais l'article à jour.
Vous pouvez également poster en commentaire vos propres Dockerfile.
Pour plus d'informations, je vous invite à aller voir le Docker Hub de l'image.
]]>Comment ignorer les changements de droits sur les fichiers ou dossiers avec Git ?
Comment visualiser les fichiers réellement modifiés ?
Comment annuler le changement de mode via Git ?
Vous avez changé les droits des fichiers ou d'un dossier avec la commande chmod
. Lorsque vous faites votre git status
vous voyez apparaître une liste de fichiers dont le mode a changé. Mais ce n'est pas utile de les commiter. Alors comment faire ?
C'est la première question à se poser !
Les droits du dépôts doivent être les droits du projet.
C'est pour celà que Git prend en compte les permissions par défaut.
Certains dossiers ont besoin de permissions particulières (les logs, le cache, uploads, ...) mais normalement il n'est pas nécessaire des les versionner.
Si vous avez un dossier qui a besoin d'un droit spécial et que ce n'est vraiment pas judicieux de le commiter, le script de déploiement effectuera l'attribution des droits nécessaires.
Mais c'est un cas très particulier.
Si vous ne rentrez pas dans ce cas particulier, c'est qu'il y a des problèmes d'accès à certains fichiers ou dossiers.
Donc, il peut être utile de les commiter après le chmod
.
Il est possible de désactiver la prise en compte des permissions pour le projet.
Placez vous à la racine de votre projet au préalable.
$ git config core.fileMode false
Cette commande va modifier la configuration git au niveau du projet.
C'est à dire directement dans le fichier de configuration : .git/config
.
Vos prochains changement de droits, ne serons plus pris en compte pour ce projet.
Cette commande est à éviter.
C'est la même commande que précédemment mais avec l'option --global
.
$ git config --global core.fileMode false
Elle permet de désactiver l'option fileMode
au niveau global (dans le fichier ~/.gitconfig
).
La configuration globale est prioritaire sur la configuration du projet.
Donc ce sera appliqué à tous vos projets. Et c'est pour ça que c'est à éviter 😉.
Il est également possible d'ignorer le changement de mode uniquement sur une commande Git.
Par exemple sur un git status
, ou un git diff
.
$ git -c core.fileMode=false diff
Vous aurez alors les toutes les différences des fichiers sans ceux qui ont eux leur permission qui a changé.
Il existe une commande pour faire ça, mais elle est un peu complexe :
$ git diff -p -R --no-color \
| grep -E "^(diff|(old|new) mode)" --color=never \
| git apply
Pour rappel, la commande git diff
prend deux entrées et affiche la différence entre les deux. Si rien n'est renseigné, les deux entrées vont être la copie de travail et la branche courante.
Pour le reste, voici le détail des paramètres, commandes utilisées :
-p
génère un patch-R
inverse la différence entre les deux entrées du diff
(ça évite de devoir parser le résultat)--no-color
désactive la colorisationgrep -E
permet...Comment afficher les logs Symfony en environnement de développement ? Comment formater l'affichage des logs pour que ce soit plus clair ?
Par défaut, les logs Symfony sont très verbeux, car le niveau est à DEBUG
.
Changer le niveau de logs à INFO
ou WARNING
risque de me faire passer à côté de pas mal de choses en cas de problème.
Ce qui m'intéresse c'est de voir facilement le niveau ERROR
et CRITICAL
, sans perdre le reste.
Pour faire ça, il a deux solutions : passer par l'IDE (ici PhpStorm) ou par la console.
Lorsque vous ouvrez votre fichier de logs avec PhpStorm, il peut vous proposer de configurer la couleur.
Il utilise les RegExp pour les parser et colorier les lignes.
Voici un exemple sur mon IDE :
Pour arriver à ce résultat, vous pouvez aller dans la configuration de votre IDE, Editor -> Log Highlighting.
Dans la partie Log Formats
, ajoutez une ligne que vous pouvez nommer comme moi : Symfony
.
Puis dans les autres champs, on va mettre :
^(.*)$
^\[
yyyy-MM-dd HH:mm:ss
1
3
2
Ensuite, on ajoute la configuration pour les patterns :
^.*\.CRITICAL.*$
, bold, Foreground #FF0000
, Background #000000
^.*\.ERROR.*$
, bold, Foreground #FF9900
^.*\.WARNING.*$
, bold, Foreground #FFFF00
^.*\.INFO.*$
, Foreground #00D66D
Évidemment, je vous laisse l'adapter suivant vos besoin !
Dans cette solution, il s'agit d'utiliser la console pour afficher les lignes qui nous intéressent le plus : ERROR
et CRITICAL
.
Les 2 commandes utiles sont tail
et grep
avec le pipe entre les deux.
Ces deux commandes sont disponibles sur MacOS et Linux par défaut, donc pas besoin de les installer.
Pour les utilisateurs de Windows, je vous recommande fortement cet outil : Cmder.
La commande que j'utilise est :
$ tail -f var/log/dev.log | grep -a --color=auto "ERROR\|CRITICAL"
La commande va écouter le fichier de logs et filtrer les lignes contenant les mots clés ERROR
ou CRITICAL
:
L'option tail -f
permet d'écouter en continue.
Et l'option grep -a
permet de dire à grep
qu'il s'agit de texte et pas de données binaires.
Il est possible d'aller encore plus loin avec la commande watch
.
Il n'y a plus besoin de passer des lignes pour voir s'il y a eu un changement, comme avec tail
.watch
lance une commande toute les n secondes et affiche le résultats.
Il ne reste plus qu'à modifier le nombre de lignes remontées par tail
(avec l'option -n 5
par exemple) pour que l'on ne lise que les dernières lignes :
$ watch -n 1 'tail...
]]>
Comment installer Symfony sur son ordinateur ? Comment installer un environnement de développement facilement pour Symfony ? Quel est le meilleur environnement ?
Pour utiliser Symfony en local, il faut un serveur web (Apache ou Nginx), une base de donnée (MySQL, MariaDB, PostgreSQL ou MongoDB), PHP 7 et toutes les extensions.
Il y a toujours Wamp, Mamp et autres, mais c'est buggé, et vraiment pas pratique. En plus cette méthode est ancienne (ouai je sais, ça fout un coup de vieux 😉).
Il y a aussi la VM Linux, mais c'est très gourmand, c'est lent et ça prend du temps à installer.
Et si vous êtes comme moi, installer tous les packages en local ça m'embêtes...
Voilà j'ai laché l'idée...
Pour ceux qui connaissent, vous pouvez passer à la partie d'après.
Sinon, je vais vous présenter tous ces outils.
Ces deux outils sont disponible sur Linux, MacOs et Windows.
Si la VM est une bière, alors Vagrant est son verre. 🍺
Vagrant est un wrapper, une couche supérieur à VirtualBox ou VMWare.
Il va permettre de créer, et gérer des VMs.
Elle seront plus légères et facilement configurables.
Un Vagrant File permet de définir les configurations et de les échanger facilement avec un autre développeur.
Cet environnement préconfiguré s'appelle une Vagrant Box.
Vagrant c'est à mi chemin entre une VM et Docker.
Personnellement j'ai pas mal devéloppé dessus. C'est plus rapide et moins gourmand qu'une vrai VM.
Laravel Homestead est une surcouche Vagrant et une Vagrant Box préconfiguré contenant tout un tas d'outils.
C'est la boîte à outils parfaite (ou presque 😉).
Cette Box contient entre autre Ubuntu, plusieurs versions de PHP (avec Xdebug et compagnie), Nginx, MySQL, PostgreSQL, Composer, MailHog, Node (avec Yarn, Bower, Grunt et Gulp), Redis, ngrok, ...
Tout ce qu'il faut pour bien développer !
L'installation n'est pas bien complexe, mais un peu longue.
Je vais vous montrer la version avec VirtualBox.
Libre à vous de faire différement si besoin.
Trois outils de base ont besoin d'être installé :
Vérifiez que tout est bien installé :
$ vboxmanage --version
$ vagrant --version
$ git --version
Ensuite il faut télécharger la box Laravel/Homestead pour Virtualbox :
$ vagrant box add laravel/homestead
Ça prend du temps, c'est assez lourd. Elle prend plus de 2Go quand même.
Puis on récupère la configuration Vagrant pour Laravel/Homestead :
$ git clone https://github.com/laravel/homestead.git ~/development
Vous pouvez remplacez le répertoire final par ce que vous voulez.
La version sur le master
n'est pas toujours stable, alors jetez...
Quelle est la différence entre un git reset HEAD
et un git rm --cached
?
Pour bien comprendre la différence entre les deux, il faut bien comprendre les états d'un fichier.
Il y en a 4 principaux :
Le répertoire de votre projet est votre copie de travail.
Les fichiers peuvent avoir deux états :
Les fichiers sont marqués comme étant prêts à être commité.
Un git status
permet de voir où nous en sommes.
Les fichiers sont commités dans cette zone par paquets ou commits.
C'est l'archivage du dépôt local.
Il va réinitialisé l'index à l'état où il était avant l'ajout de fichiers ou l'ajout de modications dans l'index (avec le git add
).
La copie de travail et l'index seront synchronisés.
Cette commande sera surtout utile pour supprimer un fichier de l'index, c'est à dire pour unstage un fichier.
Il supprime le fichier de l'index seulement et le garde dans la copie de travail (grâce à l'option --cached
).
C'est l'exact opposé du git add
.
Le fichier passe donc dans l'état non versionné et garde ses modifications.
En cas de de commit, le fichier sera supprimé du dépôt local.
Un bon dessin vaut mieux qu'un long discour :
]]>