Utilisation de typescript ou de la command tsc avec visual studio code

Lorsque vous en avez besoin, typescript ou la commande tsc sur le terminal de Visual Studio Code pourrait vous jeter en disant : "je ne connais pas ta commande, circule il y a rien à voir ici". Pour d'accord.. l'erreur n'est pas exprimé ainsi, mais je pense que vous avez compris l'idée...

Dans ce cas, on recherche les choses sur Google et nous ne sommes pas toujours trés bien orienté... Ou alors je ne sais plus chercher, ce qui est tout à fait possible, en veillissant il parait que nos capacités déclinent ^^. Trêve de plaisanteries, sur la doc on nous conseille de juste faire un 

tsc --init

et c'est magique on initialise la configuration sur typescript, ou au pire on fait un

npm install typescript

et c'est parti... Et bien en fait non. Si l'environnement n'est pas configuré ce n'est pas suffisant. Je ne peux en vouloir à Visual Studio Code pour le coup ;). Il faudra installe typescript de maniére globale avec

npm install typescript -g

Et cette fois, c'est bon vous pourrez utiliser typescript pour vos projets...

Oui, c'est un peu ridicule comme billet. Mais son principe c'est m'éviter de prendre trop de temps pour savoir ce que j'ai oublié ;) avec ma mémoire de poisson rouge.

Affaire a suivre.


Global Knowledge a interrogé 14 000 professionnels de l'informatique et des affaires dans le monde entier et a confirmé que les individus et les organisations bénéficient d'une certification informatique. Les participants ont identifié une productivité accrue et un potentiel de gain, moins de lacunes dans les compétences et un dépannage plus rapide comme avantages de la certification.

La majorité des décideurs informatiques ont indiqué que le coût de la certification est récupéré grâce à une productivité accrue, un dépannage plus rapide et une réduction des lacunes en matière de compétences. Les participants au sondage ont également indiqué une corrélation entre la certification et la sécurité d'emploi et la satisfaction.

Les professionnels de l'informatique certifiés du monde entier gagnaient beaucoup plus que leurs pairs non certifiés. Les décideurs informatiques certifiés en Amérique du Nord gagnent en moyenne 8,9% de plus que leurs pairs non certifiés; en Amérique latine et dans la zone EMEA, la différence est respectivement de 10% et 13%.


Gestion du powershell 7 et les surprises à l'installation

Si vous n'êtes pas administrateur système dans votre rôle principale au sein de votre entreprise, alors alors passer à PowerShell 7 est surprenant. Et oui, je suis multi-casquette mais du coup je ne suis pas au fil de l'eau toutes les actualités sur tous les domaines à la fois. Mon rôle principale dans mon métier est le développement logiciel, et lorsqu'on opte pour de la migration ou la création de nouvelles applications. Alors je change de casquette et je vais plutôt prendre un rôle d'architecte logicielle.

Et comme en ce moment, ou nous sommes en train d'étudier la faisabilité pour créer une nouvelle structure, alors d'autres rôles supplémentaires viennent se rajouter. Mais je m'éloigne du sujet initiale, les surprises de powershell 7.

Dans ma casquette Dev Ops ou je suis amené à industrialiser les déploiements, j'ai voulu intégrer le déploiement de service windows en utilisant les capacités de Powershell 7 qui intégre depuis la version 6 la CmdLet Remove-Service notamment. Jusqu'à maintenant, j'ai pu me contenter de la version 5.1 sur les serveurs que je gére et l'upgrade a toujours passé tout droit.

Mais aprés avoir suivi le sujet ici : https://docs.microsoft.com/fr-fr/powershell/scripting/install/installing-powershell-core-on-windows?view=powershell-7 et aprés reboot de la machine... je fus surpris qu'en lançant mon powershell j'étais toujours en version 5.1 via la commande $PsVersionTable.

J'ai cherché, cherché... et finalement j'ai vu que les raccourcis pointe sur l'ancienne versio et que beaucoup de choses ont changer aprés la 5.1 lorsque l'on lit cet article .

Et en fait si on utilise la fonction de recherche on s'aperçoit qu'il y a d'autres raccourcis pour powershell :

Et avec le bon terminal cela fonctionne bien mieux ;)

Affaire à suivre.


68% des travailleurs en Amérique du Nord estiment que cette pénurie de main-d'œuvre est due à un manque de personnel qualifié.

Raisons de la pénurie de main-d'œuvre par région

Pour aider à lutter contre l'écart croissant, un tiers des responsables du recrutement dans le monde prévoient d'augmenter la taille de leurs services de 15% ou plus. Réalisée par Frost & Sullivan pour le Center for Cyber ​​Safety and Education, avec le soutien de (ISC) 2, Booz Allen Hamilton et Alta Associates, l'enquête est la plus complète du secteur, intégrant les informations de plus de 19000 professionnels de la cybersécurité.

«On craint clairement que les emplois restent vacants, ce qui entraîne finalement un manque de ressources pour faire face aux menaces actuelles de l'industrie - parmi les travailleurs de la sécurité de l'information interrogés, 66% ont déclaré avoir trop peu de travailleurs pour faire face aux menaces actuelles. Nous allons devoir comprendre comment nous communiquons les uns avec les autres, et l'industrie devra apprendre ce qu'il faut faire pour attirer, activer et retenir les talents en cybersécurité nécessaires pour lutter contre les risques actuels », a déclaré David Shearer, PDG de (ISC ) 2.

Bref c'est un sujet d'actualité et si vous voulez en apprendre d'avantage, il faudra lire tout le billet

Affaire à suivre.


91% des personnes utilise le même mot de passe sur différents comptes à risque. Et pourtant 66% continue à utiliser le même mot de passe quoi qu'il arrive. Les expert en sécurité dans le monde numérique sont au courant des bonnes habitudes quand il faut une authentification forte, ou une gestion des mots de passe. Or trop souvent l'implémentation échoue à cause d'une utilisation trés limité et complexe.

Pour choisir une solution pour gérer les mots de passe pour votre société, vous devez penser à divers facteurs lors de la prise de décision. De ce fait il fut nécessaire de récupérer les points de vue de différents professionnel en sécurité informatique.

Sur ces derniers ce qui revient souvent c'est que le choix est orienté surtout par des profils IT sans prendre complétement les considérations des équipes sur le terrain. D'ou une adoption de ces outils trés minoritaire dans une structure. Pour vous aider à faire votre choix, le billet passera en revue les retours d'expérience de ces professionnel ayant eu ce type de choix à faire et les difficultés qu'ils ont rencontrés.

Affaire à suivre.


Chaque semaine, une autre histoire est racontée sur comment linux n'est pas sécurisé. Le seul probléme avec la plus part, ce sont des fausses actualités. Le vrai probléme réside dans l'incompétence des administrateurs systéme.

Bref il y en a mare des :

Comme tous les systémes d'exploitation, linux n'est pas parfaitement sécurisé. Mais comme le dit le Guru Bruce Schneier, "La sécurité est un processus, pas un produit". C'est juste une maniére de parler, linux est plus sécurisée nativement que la plupart des autres systémes d'exploitation. Vous ne pouvez pas dire à partir des récentes histoires sur les manquement en terme de sécurité de la plateforme linux. Mais si vous regardez attentivement ces histoire la pluspart sont communiquées en tant que bugs.

Par exemple, Boothole semblait trés effrayé. Vous pouvez obtenir un accès root sur n'importe quel systéme. Oh non! Le groupe qui l'a découvert vient tout de suite spécifié qu'un attaquant a besoin d'un accès administrateur pour que son exploit fonctionne.... Heu comment dire. Si un utilisateur a des accès root, vous avez déjà de vrais problémes quoiqu'il arrive. Et cela pas besoin d'avoir à utiliser une faille... Vous vous souvenez de ce que j'ai dit que Linux n'est pas parfait ? C'est l'exemple parfait. Le probléme de base était bien plus dangereux pour un système déjà piraté. Ms ais plusieurs distributeurs linux ont baclé le correctif initial au point que leur systéme ne pouvait plus redémarrer. C'est mauvais.

Quelque fois corrigé le probléme dans l'urgence peut rendre les choses pire et c'est ce qui s'est passé ici.

Si ce genre de cas vous intéresse, n'hésitez pas à lire tout le billet.


Lors du développement d'une fonctionnalité d'upload, l'équipe de développement est trop focalisé sur l'objectif car elle a durant cette étape trop souvent la tête dans le guidon et ne prends pas le recul nécessaire de l'impact d'une telle fonctionnalité. Et ce aussi bien au niveau des performances que de la sécurité, car il faut faire cela vite car ce besoin arrive en urgence car il a souvent été oublié dans le processus de spécifications et les impacts de cette fonctionnalité sur la sécurité de la si est complétement mis de côté, du moins trop souvent...

Or mettre en place les éléments après l'incendie est souvent trop tard, car le mal aura dèjà pris racine. Ouvrir un flux d'upload, c'est équivalent a potentiellement laissé la porte ouverte de sa maison. Et oui, avec un fichier compromis on peut rentrer dans la SI de la plateforme, et une fois la porte ouverte c'est compliqué de la refermer. C'est le même principe que les squats en France... la porte reste trop longtemps ouverte et il n'est plus possible de déloger les personnes, dans notre contexte, je parle bien sur des hackers.

Mais le design de cette fonctionnalité d'upload peut aussi faire en sorte d'économiser des ressources. En utilisant des techniques comme le buffering, cela va vous éviter de multiplier des serveurs pour rien.

Bref, si ce sont des sujets qui attire votre attention alors je vous invite à lire le billet qui vous expliquera tout cela en détail.

 


Validation utilisateur dans le cas des uploads de fichier

S'assurer d'avoir mis en place les contrôles de validation lors d'un upload de fichier avant d'accepter les fichiers des utilisateurs est important. Comme vous avez pu le lire sur différents billets que j'ai publié récemment, ce mécanisme est le premier vecteur d'attaque d'une plateforme.

Ainsi dès que l'on vous demande de créer un tel mécanisme pour une application voici une liste d'étapes à faire pour minimiser les risques sur votre SI:

  • Vérifier les extensions de fichier (surtout pour éviter d'accepter des fichiers potentiellement dangereux)
  • Définir une taille limite lors de l'upload (évite de surcharger la bande passante, et l'espace disque du serveur)
  • S'assurer de l'endroit ou son déposer les fichiers. Dans l'idéal en dehors de l'arborescence de l'application, mais aussi sur un lecteur qui n'est pas celui ou se trouve le système d'exploitation.
  • Une convention de nommage devrait-être suivi ce qui permet d'éviter de récupérer des noms issus de l'utilisateur ou métadonnées du fichier qui peuvent-être piégées.
  • Les fichiers doivent-être analysés ainsi que les métadata pèar un antivirus pour s'assurer de ne pas se retrouver avec un fichier ou données compromises.
  • La signature du fichier doit-être vérifier, pour éviter de se retrouver avec un exe malgé le fait que l'extension finale soit un .txt


Parfois, le navigateur vous joue des tours et il ne tient pas compte de vos désir sur le comportement lors du téléchargement d'un fichier. C'est plus particuliérement vrai avec Firefox. Je ne sais pas si c'est les derniéres versions qui ont se comportement, en tout cas sur les versions de  62.x à 68.x, j'ai identifié cette problématique.

Lorsque j'ai eu à utiliser selenium pour piloter firefox dans le cadre de tests d'acceptance, je me suis retrouvé à ne pas réussir à piloter le téléchargement de fichier au sein de Firefox. Ayant eu beaucoup de difficultés à trouver une solution fonctionnelle, j'ai donc décidé d'écrire un bilet afin de partager ma solution (et surtout pour moi en fait, afin que je puisse la retrouver si à l'avenir j'en ai besoin).

Le probléme principale réside finalement dans le fait que Firefox ne permet pas de modifier facilement par type de fichiers, la maniére dont on veut qu'il gére le téléchargement, à savoir s'il demande ou effectuer le téléchargement, le téléchargement direct, ou encore l'ouvrir. C'est pourtant quelque chose de simple. Mais avec Firefox ce fut quelque chose de trés compliqué.

Dans la lecture du billet, je vous dévoile tout.


Pouvoir recevoir des fichiers des utilisateurs sur sa plateforme représente un gros risques pour les applications mais également pour le système d'information dans sa globalité. C'est la premiére étape pour la pluspart des attaque sur un système. Car le but d'une telle recherche est finalement de trouver un moyen pour executer son propre code. Et utiliser un fichier que l'on peut uploader directement sur l'infrastructure cibler et donc naturellement l'une des première tentative.

Les conséquences avec un mécanisme d'upload qui ne contient aucune restriction sont trés variable, cela passe de la prise en main complète de la SI, à pouvoir surcharger le système ou écraser les données. Cela dépend de ce que fait l'application et de l'endroit de stockage.

Il y a deux catégories de problèmes dans ce type de scénario. Le premier est lié aux métadatas associés au fichier, comme le chemin et le nom de fichier. Ce sont généralement des données générées durant la phase de transport entre l'utilisateur et l'application au travers de la couche d'encodage multipart http. Ces données peuvent être modifiées de maniére à piégier l'application en surchargeant des fichiers critiques par exemple en stockant le fichier au mauvaise endroit. Il est donc nécessaire de valider les métadatas avec rigueur avant de les utiliser. L'autre catégorie de problème concerne la taille des fichiers ou du contenu. La plage des conséquences dépend de l'usage du fichier. Aussi, vous devriez analyser tout ce que fait l'application avec les fichiers et réfléchir à la maniére de gérer le processus et interprété son contenu.  

De ce fait, mettre en place un upload sans restriction est une trés mauvaise idée. Si ce préambule vous a donné d'en savoir plus sur ce sujet, je vous invite à lire tout le billet.

Affaire à suivre ;)