À ce stade, nous avons tous entendu des histoires d’horreur sur le fait de cliquer sur des liens malveillants, et si nous sommes assez malchanceux, nous avons peut-être fait l’objet d’une de ces histoires.
En voici un que nous reconnaîtrons probablement tous : un employé sans méfiance reçoit un e-mail d’une source apparemment digne de confiance, et cet e-mail prétend qu’il y a eu une tentative de violation de l’un de leurs comptes en ligne les plus importants. L’employé, ressentant un sentiment d’effroi immédiat, clique instinctivement sur ce lien, espérant sauver la situation avant que la direction ne s’en rende compte. Lorsqu’ils suivent ce lien, ils sont confrontés à une interface de connexion qu’ils ont l’habitude de voir – du moins le croient-ils. Saisir son email et son mot de passe est une seconde nature : il saisit ces informations rapidement et clique sur « entrer » sans trop réfléchir.
Dans sa précipitation, cet employé n’a pas remarqué que l’interface de connexion était très différente de la normale. De plus, ils ont oublié que l’adresse e-mail les alertant de cette « violation » de compte contenait 10 caractères de plus qu’elle n’en aurait si elle provenait du fournisseur de compte. En plus de tout cela, ils n’ont pas réussi à voir que le lien lui-même – un mélange de lettres, de symboles et de mots très serrés qu’ils ont à peine jeté un coup d’œil dans le meilleur des cas – contient des orthographes et des caractères inappropriés. partout. En 30 secondes environ, cet employé a involontairement compromis un compte avec accès à certaines des données les plus sensibles de son employeur, donnant ses identifiants de connexion à un cybercriminel éloigné qui perdra sans doute peu de temps à exploiter la situation à des fins lucratives.
Un scénario standard d’hameçonnage par e-mail comme celui-ci – l’exemple le plus élémentaire d’une tactique d’ingénierie sociale éprouvée, remontant aux premiers jours d’Internet – n’est qu’une des nombreuses menaces impliquant des URL qui continuent de susciter un examen minutieux autour du origine et diffusion de liens malveillants. Au fur et à mesure de l’évolution d’Internet, l’utilité des URL s’est développée en parallèle. Nous utilisons des URL pour partager tout le temps du contenu important avec nos amis, collègues, responsables, clients et clients, en veillant discrètement à ce que les URL puissent continuer à se développer dans leur rôle de vecteurs d’escroqueries par ingénierie sociale, de virus, de logiciels malveillants et de diverses autres formes de menaces de cybersécurité.
De cet examen minutieux, une culture de responsabilité individuelle a principalement émergé : nous, les cibles des URL menaçantes, sommes (à juste titre) considérés comme la barrière la plus importante entre l’attaque et la violation. Par conséquent, au niveau organisationnel, la mesure la plus importante et la plus courante prise pour atténuer ce problème consiste à former les utilisateurs à la détection par eux-mêmes des liens frauduleux. Les employés d’entreprises de divers secteurs du monde entier apprennent de plus en plus à identifier les signes évidents de liens malveillants (et l’ingénierie sociale/la sensibilisation non fiable), une pratique qui s’est sans aucun doute avérée très bénéfique pour réduire les cas de violation par URL.
Cependant, le vaste potentiel criminel des URL signifie que la formation des utilisateurs n’est pas tout à fait suffisante pour atténuer entièrement le problème. Pour sécuriser correctement nos précieuses données, nous devons mettre en œuvre de manière proactive des politiques de sécurité capables d’identifier et de signaler avec précision les menaces basées sur les URL. Comme les tendances des virus vivants, les stratégies sous-jacentes des menaces URL (et de toutes les menaces de cybersécurité) évoluent inexorablement pour vaincre leurs victimes, diminuant l’utilité des formations de sécurité passées jusqu’à ce que leur pertinence soit au mieux douteuse.
Par exemple, les URL sont de plus en plus utilisées comme méthode légère de partage de fichiers sur un réseau. Lorsque nous recevons un lien vers un fichier d’une personne de confiance (dont nous recevons régulièrement des fichiers), nous avons peu de raisons de croire que ce lien peut être compromis et, malgré toute notre formation intense en matière de sécurité, nous risquons toujours de cliquer dessus. À notre insu, ce lien peut contenir un fichier ForcedDownload malveillant qui cherche à capitaliser sur notre brève erreur de jugement et à compromettre notre système avant que nous puissions réagir. Bien que la responsabilité individuelle signifie que des erreurs comme celle-ci devraient (et seront) considérées comme notre faute à court terme, ce blâme a une capacité limitée à dissuader le problème à mesure qu’il continue d’évoluer. La personne qui nous a envoyé ce lien peut l’avoir reçu d’une source ils font généralement confiance, et cette source peut l’avoir reçue de quelqu’un ils aussi font généralement confiance, et quelqu’un vers le début de cette chaîne de communication peut n’avoir reçu aucune formation en matière de sécurité dans son travail, transmettant aveuglément des liens à partir d’une source qu’il croyait être précieuse mais n’avait jamais réellement enquêté auparavant. Tout comme il est important pour nous de supposer que des liens tels que celui-ci pourraient être dangereux, il est tout aussi important que les politiques de sécurité de notre système assument la même chose et agissent contre ces liens avec autant de diligence que possible avant qu’ils n’atteignent une couche humaine de discrétion.
À cette fin, les API de sécurité des URL peuvent jouer un rôle clé, offrant un service efficace et à valeur ajoutée à notre architecture d’application tout en supprimant certaines des charges pesant sur nos utilisateurs pour empêcher les liens malveillants de compromettre nos systèmes par eux-mêmes.
Manifestation
Le but de cet article est de fournir une API REST puissante et gratuite qui analyse les URL des sites Web à la recherche de diverses formes de menaces. Cette API accepte une chaîne de lien de site Web (commençant par « http:// » ou « https:// ») en entrée et renvoie des informations clés sur le contenu de cette URL en peu de temps. Le corps de la réponse inclut les informations suivantes :
- « Résultat propre » – Un booléen indiquant si le lien est propre ou non, garantissant que ce lien peut être détourné immédiatement de sa destination prévue« Type de menace de site Web », une valeur de chaîne identifiant si la menace sous-jacente au sein du lien est de type Malware, ForcedDownload ou Phishing (les liens propres renverront « none »)
- « Virus trouvés » – Une sous-section de virus (« VirusName ») trouvée dans une URL de fichier donnée (« FileName »), et le nom de ces virus
- « Site WebHttpResponseCode » – Le code de réponse HTTP à trois chiffres renvoyé par le lien
Pour effectuer une demande d’API gratuite, une API de niveau gratuit est requise et peut être obtenue en enregistrant un compte gratuit sur le site Web Cloudmersive (veuillez noter que cela donne une limite de 800 appels d’API par mois sans engagement).
Pour tirer parti de cette API, suivez les étapes ci-dessous pour structurer votre appel d’API en Java à l’aide d’exemples de code complémentaires prêts à l’emploi.
Pour commencer, votre première étape consiste à installer le SDK Java. Pour installer avec Maven, ajoutez la référence ci-dessous au référentiel dans pom.xml :
<repositories>
<repository>
<id>jitpack.io</id>
<url>https://jitpack.io</url>
</repository>
</repositories>Pour terminer l’installation avec Maven, ajoutez ensuite la référence suivante à la dépendance dans pom.xml :
<dependencies>
<dependency>
<groupId>com.github.Cloudmersive</groupId>
<artifactId>Cloudmersive.APIClient.Java</artifactId>
<version>v4.25</version>
</dependency>
</dependencies>Pour installer avec Gradle à la place, ajoutez-le à votre racine build.gradle à la fin des référentiels :
allprojects {
repositories {
...
maven { url 'https://jitpack.io' }
}
}Ensuite, ajoutez la dépendance dans build.gradle, et vous avez terminé l’étape d’installation :
dependencies {
implementation 'com.github.Cloudmersive:Cloudmersive.APIClient.Java:v4.25'
}Une fois l’installation terminée, notre prochaine étape consiste à ajouter les importations et à appeler l’API Virus Scan :
// Import classes:
//import com.cloudmersive.client.invoker.ApiClient;
//import com.cloudmersive.client.invoker.ApiException;
//import com.cloudmersive.client.invoker.Configuration;
//import com.cloudmersive.client.invoker.auth.*;
//import com.cloudmersive.client.ScanApi;
ApiClient defaultClient = Configuration.getDefaultApiClient();
// Configure API key authorization: Apikey
ApiKeyAuth Apikey = (ApiKeyAuth) defaultClient.getAuthentication("Apikey");
Apikey.setApiKey("YOUR API KEY");
// Uncomment the following line to set a prefix for the API key, e.g. "Token" (defaults to null)
//Apikey.setApiKeyPrefix("Token");
ScanApi apiInstance = new ScanApi();
WebsiteScanRequest input = new WebsiteScanRequest(); // WebsiteScanRequest |
try {
WebsiteScanResult result = apiInstance.scanWebsite(input);
System.out.println(result);
} catch (ApiException e) {
System.err.println("Exception when calling ScanApi#scanWebsite");
e.printStackTrace();
}Après cela, vous avez terminé – plus aucun code n’est requis.