Par Geoffrey, CTO et Clément, Lead Developer au sein de l’Agence Dn’D
Nous étions il y a quelques semaines à l’événement PHP de l’année qui se déroulait à Disneyland dans l’Hôtel Marvel : la 23ᵉ édition du Forum PHP 2022 ! Cet événement, organisé chaque année par l’AFUP, est l’occasion pour tous les participants de se retrouver autour de thématiques centrées sur l’écosystème PHP.
Le programme de cette année était particulièrement riche, avec au programme des mathématiques, du réseau, des innovations, de la sécurité. Des sujets passionnants pour ces deux journées, en plus de belles rencontres.
Watch the clock
Andreas HEIGL nous présente, à travers sa conférence, la norme PSR-20 qui a pour objectif de standardiser les librairies qui fournissent le temps.
L’interface est plutôt simple :
interface ClockInterface
{
public function now (): DateTimeImmutable;
}Nous pourrons l’utiliser de cette façon :
class Foo {
public function construct(private ClockInterface $clock) {}
public function doSomething(): void
{
/* @var DateTimeImmutable */
$now = $this->clock->now();
//Do whatever needs to be done
}
}Comment décide-t-on de créer un composant Symfony ?
Nicolas Grekas contribue professionnellement à la durabilité de l’entreprise Symfony. Lors de sa conférence, il choisit de nous parler d’un sujet intéressant : pourquoi choisir de faire un composant Symfony plutôt que d’utiliser un composant open source existant ?
Nicolas commence la conférence en rappelant les enjeux de Symfony :
- Symfony 2 Open Source Software est sorti en 2011.
- Symfony est le framework PHP le plus utilisé (4000 contributeurs)
- Symfony c’est 60 core components et 200 packages
Certaines créations de composants ont créé des polémiques. C’est par exemple le cas du composant HttpClient, puisque nous avions Guzzle.
Les raisons :
- Pas de maîtrise des releases de Guzzle (trop de versions sorties avec des backward incompatibilities)
- La team Symfony devrait garantir la qualité du package.
- Maîtrise de la stabilité du composant.
Le composant Uid à lui aussi créé une polémique, puisque nous utilisions ramsey/uuid.
Les raisons :
- ramsey/uuid nécessitait une extension installée (le but est de réduire les dépendances avec Symfony).
- Le composant Symfony est beaucoup plus simple.
La création de nouveaux composants avec Symfony permet d’inciter les développeurs à découvrir de nouveaux concepts grâce à la visibilité du framework.
Enfin, Nicolas termine sa conférence en rappelant les principes de Symfony :
- Predicable releasing policy
- Mono-repository
- Backward-compatibility promise
- Forward-compatibility promise
- Deprecation Policy
- Core-Team
- Security Policy
- Welcoming spaces
- CARE Team
- Friendly CI
Et les “Principles of Package Coupling” :
- Acyclic dependencies
- Stable dependencies
- Stable abstractions
Cette conférence nous a permis de mieux comprendre ce qui pousse les équipes Symfony à créer de nouveaux composants, pour nous assurer une meilleure stabilité et une meilleure flexibilité de framework.
Comment protéger les applications avec CSP ?
Laurent BRUNET présente un sujet très intéressant pour nous, puisque la CSP est un dispositif mis en place nativement sur Adobe Commerce.
Ce qui ressort de cette prise de parole :
- La Content Security Policy permet de réduire plusieurs types d’attaques, dont l’une de plus connue : l’injection XSS.
- La CSP a été introduite depuis 2012 est supportée par la majorité des navigateurs aujourd’hui. Pour l’activer, il vous suffira d’ajouter l’entête HTTP Content-Security-Policy aux réponses.
- Les attaques XSS sont de plus en plus nombreuses depuis quelques années. La CSP permet de s’affranchir de ces attaques, mais doit être parfaitement configurée.
- La whitelist est contournable d’après un article de Google écrit en 2016.
D’après Google, 95 % des sites qui implémentent la CSP sont vulnérables !
Pour améliorer la configuration des CSP, il existe des validateurs en ligne : csp.withgoogle.com.
@storyset – Freepik
Laurent nous parle des différentes attaques possibles et de la façon de les parer à l’aide de la CSP :
- Clickjacking : utilisation de la directive frame-ancestors
- Protocoles sécurisés : Forcer le https avec la directive default-src ‘self’ https: wss:;
- Protocoles sécurisés : Transforme les requêtes non HTTPS en HTTPS avec la directive upgrade-insecure-requests
La CSP a la possibilité de logguer directement dans la console du navigateur. Il est impossible de pouvoir suivre l’évolution, d’identifier des attaques avec ce type de log. C’est pour cette raison que des sites permettent de répertorier et de suivre les logs de CSP de votre site :
- urireports.com
- uriports.com
- csper.io
- sentry.io
- datadoghq.com
- raygun.com
Laurent termine sa conférence sur un type d’attaque que nous connaissons bien : MageCart. Les premières attaques ont été identifiées en 2015.
Ces attaques ciblent principalement les sites sur Magento (Adobe Commerce). Leur but est de récupérer les données de paiement dans le tunnel d’achat, en injectant quelques lignes de script faisant un appel ajax externe, pour transmettre les données de paiement.
Pour bloquer ce type d’attaque, il est nécessaire d’utiliser la directive « connect-src ». Elle permet de bloquer les appels AJAX qui n’ont pas la même origine (connect-src ‘self’).
Nous publierons prochainement un article sur le sujet…
Revue de code
Anne-Laure De Boissieu commence sa présentation en abordant le terme Egoless programming, et met en situation la façon dont un développeur pourrait prendre des retours de revue de code factuel du type :
- Pas bon
- À revoir
- Etc.
Un excellent livre écrit par Richard Weinberg traite d’ailleurs du sujet : The psychologiy of computer programming. Weinberg (1971).
Anne-Laure précise qu’il faut comprendre une chose « Your are not your code »! Autrement dit : toutes les critiques qui sont faites contre le code ne vous concernent pas, mais traduisent la volonté de produire un code de qualité en équipe.
Pour éviter l’interprétation de chacun et l’ambiguïté liée au manque de contexte, il existe les Conventional Comments, des spécifications qui permettent d’améliorer la communication à travers les commentaires.
Le format se présente comme ceci :
<label> [decorations]: <subject>
[discussion]- Label – Il s’agit d’une étiquette unique qui indique le type de commentaire laissé. (ex : praise, nitpick, suggestion, question, …)
- Subject – C’est le message principal du commentaire.
- décorations (optional) – Ce sont des étiquettes de décoration supplémentaires pour le commentaire. Ils sont entourés de parenthèses et séparés par des virgules.
- Discussion (optional) – Cela contient des déclarations à l’appui, le contexte, le raisonnement et toute autre chose pour aider à communiquer le « pourquoi » et les « prochaines étapes » pour résoudre le commentaire.
Enfin, vous pourrez utiliser Github ou Gitlab, qui vous permettront de mettre en place ce standard plus facilement.
FrankenPHP, dans les entrailles de l’interpréteur PHP, de machines virtuelles et des threads
Kévin Dunglas, créateur du framework API Platform ainsi que des projets Mercure et Vulcain, nous parle de son projet FrankenPHP. Nous avions eu l’occasion de le découvrir à l’Afup Day de Lille.
Ce programme permet d’allier les évolutions dans le langage GO avec C pour interpréter du PHP.