Antichesse (o ^ω^ o)
Un tuto simple parlant de l''injection CRLF avec les loggers en Kotlin/Java.
Penser à ajouter la dépendance suivante pour se prémunir de cela avec LogBack :
<dependency>
<groupId>org.owasp</groupId>
<artifactId>security-logging-logback</artifactId>
<version>1.1.6</version>
</dependency>(à voir avec ce que propose la 1.4.4 de LogBack sortie récemment).
Edit
Une autre façon de se protéger du problème est de se servir de la fonction replace de logback en lui demandant d'effectuer un search & replace de tous les caractères de type CR/LF by une chaîne connue (ici {EOL}) qui permettra de détecter l'injection de nouvelles lignes dans les logs :
<included>
<appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">
<encoder>
<pattern>%replace(%msg){'[\r\n]', '{EOL}'}</pattern>
</encoder>
</appender>
<root level="INFO">
<appender-ref ref="STDOUT" />
</root>
</included>
Cool, Apple ne vous authentifie plus et se contente de vous identifier avec vos données biométriques personnelles (parce que c'est tout à fait normal de confier ses données biométriques à une société commerciale, vous en conviendrez #Facepalm).
Dit autrement, si quelqu'un venait à vous voler votre empreinte, votre image ou quoi que ce soit qui ne soit pas révocable, vous devrez faire face à un très gros problème.
Bref, l'authentification c'est la preuve que la personne est bien celle qu'elle prétend être. L'identification, c'est la déclaration de cette prétention mais sans preuve puisque n'importe qui peut vous voler votre ADN, vous prendre en photo, etc.
Le point du litige est que l'on peut décider de changer de mot de passe quand on veut et sans effort mais ça n'est pas possible de changer de visage, d'ADN, d'empreintes, etc.
Nous sommes à la mi 2022 et la Caisse d'Épargne n'est toujours pas fichue d'employer des développeurs qui comprennent qu'on ne peut pas partager des requêtes avec des sous-domaines lorsque l'on active le contrôle de sécurité Same Origin !
Blocage d’une requête multiorigine (Cross-Origin Request) : la politique « Same Origin » ne permet pas de consulter la ressource distante située sur https://www.as-ex-ano-groupe.caisse-epargne.fr/api/oauth/v2/token. Raison : échec de la requête CORS.
Blocage d’une requête multiorigine (Cross-Origin Request) : la politique « Same Origin » ne permet pas de consulter la ressource distante située sur https://fonts.gstatic.com/s/ubuntu/v20/4iCv6KVjbNBYlgoC1CzjsGyN.woff2. Raison : échec de la requête CORS.
downloadable font: download failed (font-family: "Ubuntu" style:normal weight:300 stretch:100 src index:0): bad URI or cross-site access not allowed source: https://fonts.gstatic.com/s/ubuntu/v20/4iCv6KVjbNBYlgoC1CzjsGyN.woff2Et tout leur site est bloqué pour un pauvre token et deux polices de caractères ! Mais leurs développeurs / sous-traitant sont nuls ! C'est incroyable que le B.A.BA ne soit pas maîtrisé à ce point. On se croirait chez ERDF / Enedis (ceux qui y sont passés doivent me comprendre) #FacePalm
Edit : en fait le site a été conçu pour Chrome et je suis sous Waterfox (une fork de Firefox sans les problèmes inhérents à Mozilla / Google). Bref, des polyfills JS sont chargés et font du cross-origin et forcément personne n'a lancé un Firefox like pour vérifier que ça marche...
À toutes ces personnes qui font du spécifiques Chrome je souhaite que ça vous gratte en permanence et à mort quelque part et qu'à chaque fois que votre doigt s'approche du point qui vous démange, celui-ci se déplace !
Après Log4j au tour de Spring d'avoir sa faille zero-day.
Comment créer un environnement sécurisé avec chroot. Plus le temps passe et plus je me dis que docker n'est pas si nécessaire.
A tous les non informaticiens, si vous vous demandez ce qu'est une "backdoor" (ou "porte dérobée" en français). Si vous vous demandez pourquoi tous les informaticiens râlent dès que l'état demande à disposer de clefs numériques privées pour déchiffrer nos communications, et bien l'analogie avec le monde réel est là.
Une seule clef permettant d'ouvrir toutes les boites à lettres, sauf que si cette clef tombe entre de mauvaises mains (ou une de ses copies), cela devient une catastrophe.
Tiens j'étais passée à côté de ça. Microsoft tente encore une fois de vendre de l'identification pour de l'authentification.
J'avais fait un post à ce sujet il y a quelques temps et je n'ai toujours pas changé d'avis sur la question.
Une fois notre image compromise, une fois que quelqu'un sera parvenu à nous filmer / photographier / enregistrer (emprunte vocale), voire de poster ces images/vidéos sur des réseaux sociaux (chose qui n'arrive jamais n'est-ce pas), alors comment changer de visage ou de voix ensuite ? Via de la chirurgie plastique ? Ça fait cher la resécurisation d'un compte compromis...
D'autant que cette chirurgie bloquera l'accès à tous les comptes sur les autres réseaux sociaux/pro/etc le temps qu'on leur réapprenne et que l'on prouve que cette nouvelle tête, c'est bien nous.... LOL
Le mot de passe est certes contraignant mais c'est le seul et unique système qui puisse être révoqué en cas de corruption. Tout le reste n'est que prétexte pour absorber nos données ou caractéristiques personnelles.
Merci à je ne sais plus qui pour le lien.
Le problème que j'ai avec l'application, c'est qu'elle associe un périphérique qui se perd, qui se casse et surtout qui se fait voler (coucou le métro parisien) à votre compte.
L'autre problème est que ces applications ne sont disponibles que sur les stores Google et Apple, or comment faire lorsque l'on utilise n'y l'un ni l'autre ?
Enfin, ces applications ne sont en général pas open-source, donc aucun moyen d'être certain qu'elles n'aspirent pas toutes les données persos...
Bref, les niveaux 3/2/1 sont au même degré de sécurité pour moi, seulement si l'on prend l'aspect global de la chose, c'est-à-dire vol du device + vol des données personnelles bien-sûr.
Si j''ai bien compris, toute la sécurité du DRM Widevine repose sur le fait que la clef privée permettant de déchiffrer les flux audio/vidéo ne soit pas volée côté client lorsqu'elle est envoyée au navigateur...
Redisons-le nous deux trois fois en décomposant bien les étapes afin d'identifier ce qui clocherait :
- Widevine envoie une clef privée aux navigateurs...
- Widevine envoie une clef privée...
- Une clef privée.
Si la clef qui doit restée privée est communiquée à toute la terre entière c'est qu'elle n'est plus privée bon-sang ! Je compte regarder dans le détail ce qu'il en retourne mais si c'est bien ce que je pense, alors le fait que Google n'emploierait que "les meilleurs des meilleurs des meilleurs Monsieur... Avec mention Monsieur" ne serait bel et bien qu'un mythe !
La petite citation qui va bien :
En plus de cette demande, nous avons déposé une demande distincte de retrait des données sensibles de ce fichier : /widevine-l3-decryptor, parce qu’il contient la clé privée secrète Widevine RSA, qui a été extraite du CDM de Widevine et peut être utilisée dans d'autres technologies de contournement.
@Guigui : super je me le note. Merci !
Brihx merci pour le lien. Par contre le coup des fonctions de dérivation de clefs qui doivent êtres rejouées n-fois pour éviter le brut-force j'ai toujours trouvé cela stupide et je m'explique.
Le but d'augmenter le nombre d'itérations est de ralentir l'algorithme de hash/crypto afin de se protéger des attaques de type brut-force. Or la puissance de calcul augmentant sans cesse avec le temps, plus les générations de CPU passent et plus il faut augmenter ce nombre d'itérations, ceci encore et toujours, jusqu'à consommer tout le pétrole sur terre pour le calcul d'un simple hash...
Sinon, on arrête de coder comme des profs de math débiles et on ajoute un Thread.sleep(1000) après le calcul du hash. Comme ça et quoi qu'il arrive, le check d'un mot de passe prendra toujours au moins 1 seconde quelque soit le CPU derrière, évitant ainsi les attaques du type brut-force, et en plus ça évite de contraindre un algo à utiliser un proc à 100% pour rien et ainsi de exposer son service à des attaques de type DDos.
Après ce n'est pas le rôle des matheux de coder efficace, c'est à nous (les IT) de comprendre ce qu'il faut faire et de bien le faire.
Outch, la dernière version stable est touchée (1.3.72). Il est recommandé de migrer vers la 1.4.0 aussitôt qu'elle sera publiée.
La criticité est de 8.8/10, avec une faille permettant une élévation de privilèges, ça fait mal.
Edit : je n'avais pas vu mais Kotlin 1.4.0 était déjà sortie. Il semble que le NIST et l'OWASP aient publié l'info qu'une fois la nouvelle version de Kotlin fût corrigée et publiée par JetBrains. C'est très pro !
Alerte au gogol ! Alerte au gogol les enfants
Boursorama en ajoutant des trackers de serveurs de pub sur son site permet à des sociétés tierces d'accéder aux comptes de ses clients. Bravo, zetes des champions...
C'est un scandale, information à faire tourner autant que possible en espérant que le bad-buzz leur serve de leçon !
Je viens de tester chez Free et Free Mobile => les deux sont 100 % ok.
@Chlouchloutte t'es pas chez Orange ou Sosh pour nous dire ?
@Riduidel et encore le pire c'est lorsqu'on regarde le code même vite-fait !
Certaines classes de tests sont des coquilles vides qui chargent un contexte Spring qui sera rechargé la classe d'après... (Encore ça admettons)
Mais la cerise sur le gâteau c'est ce test qui montre que côté cryptographie ils utilisent 3DES.
Pour ceux qui ne le saurait pas, 3DES (ou Triple DES) est sensible à plusieurs attaques de différents types réduisant la taille de clef la clef privée de 168 bits à 80 bits et que le NIST considère comme déprécié depuis trois ans déjà ; heureusement qu'il n'agit d'une application qui ne contiendrait que les données personnelles de tous les français.
Euh... Attendez une seconde... (눈_눈)
Edit : en fait j'ai lu un peu vite car ce test est bien une classe de test mais qui ne contient qu'une main() et donc qui n'est pas un test... Pareil, je n'avais pas vu le répertoire test dans src/test/java... Ni tous les TU qui n'ont aucune assertion et donc qui ne sont pas des TU mais des fonctions qui s'exécutent et dont le résultat est validé avec "ses petits yeux" par le développeur !!! À ce niveau-là ça n'est plus de l'amateurisme, c'est une forme d'Art aux antipodes du Software Craftsmanship.
Un très bon article sur JWT et comment assurer l'authenticité d'un token et par corollaire la répudiation d'un token douteux.
Je cite @Sebsauvage :
Un peu violent mais sûrement efficace: Quand PortSentry détecte des connexions sur les services fictifs qu'il expose, il bloque l'IP source.
Du coup via Sebsauvage.
Bon, je testerai dès la rentrée cette n-ième faille de sécurité de Windows ! lol
Bon bah tout est dans le titre... Dans ce post j'affirmais que :
Vous pouvez ne faire confiance à personne en ce qui concerne votre vie privée. Les meilleures boites se font hacker tous les jours et celles dont on ne parle pas ou peu sont juste celles qui sont meilleures pour étouffer les affaires !
Est-ce que vous pensez qu'il existe des sociétés ayant plus de moyens que Facebook, pouvant se payer de meilleurs ingénieurs que Facebook et détenant autant de données sensibles et intimes que Facebook ? (Pour info, le développeur-architecte sénior est à 950 K$ / an en 2019 chez Facebook hein).
Ca restreint pas mal le champs des possibles n'est-ce pas ? Et pourtant Facebook s'est encore une fois transformée en passoire... Dégagez votre appli Facebook, cette immondice est littéralement un spyware ; et pour votre santé mentale je vous recommanderais de dégager aussi Facebook de votre vie !