Quelqu'un a-t-il déjà pensé à faire cela?

Oui, il y a eu une discussion à ce sujet exactement à la defcon 21 ( vidéo, diapositives).

Leur conclusion est que l'utilisation de codes de réponse en tant que sécurité offensive peut parfois entraîner un ralentissement sévère des scanners automatiques, des scanners qui ne fonctionnent pas et une quantité massive de faux positifs ou faux-négatifs (cela ne fera évidemment que peu ou rien pour les scans manuels).

Alors que la sécurité par l'obscurité ne devrait jamais être votre seule défense, elle peut être bénéfique comme défense en profondeur (autre exemple: il est recommandé de ne pas diffuser les numéros de version de tous les composants utilisés).

D'un autre côté, une API REST doit être aussi propre que possible, et répondre avec des codes HTTP volontairement erronés peut être déroutant pour les développeurs et les clients légitimes (c'est un peu moins un problème pour les navigateurs, où les utilisateurs ne voient pas réellement les codes). Pour cette raison, je ne le recommanderais pas dans votre cas, mais c'est toujours une idée intéressante.

Cela ne ralentira pas vraiment un attaquant de manière appréciable, mais cela rendra les futurs développeurs travaillant sur votre plate-forme vraiment ennuyés contre vous. Cela peut également empêcher certaines fonctionnalités intéressantes de vos bibliothèques de requêtes HTTP, car elles fonctionnent à partir d'informations incorrectes.

Il s'agit d'une forme très faible de sécurité par l'obscurité. Lors de la conception d'un système comme celui-ci, vous devriez penser à ralentir un attaquant de centaines d'années, pas de dizaines de minutes, sinon vous allez toujours perdre.

Plutôt que de renvoyer un "401 Unauthorized", pourquoi ne pas renvoyer par exemple «305 Use Proxy», c'est-à-dire être délibérément déroutant.

Oui, cela déroutera un attaquant. Mais pour un entraîneur, cela ne durera peut-être pas plus de deux secondes. Et les codes d'état ne sont pas très utiles, principalement juste pour forcer les noms de fichiers.

Disons que j'ai une clé valide, et je peux vous observer renvoyer des codes de 200 plages pour mon authentification. Si je change un peu ma clé, et pour chaque demande que vous retournez 305s, je penserai immédiatement "Hmm. On dirait que le développeur a peut-être foiré". Si vous renvoyez des codes aléatoires, je saurai que c'était exprès et je les ignorerai simplement.

la difficulté de rétro-ingénierie d'une application iOS dissuadera tous les hackers sauf les plus déterminés

Oui, mais comme il n'en faut qu'un pour le publier, cela ralentit encore une fois.

C'est la sécurité par l'obscurité, c'est-à-dire qu'elle n'offre pas du tout beaucoup de sécurité. La solution que vous proposez ne fera que ralentir un attaquant, pas l'empêcher d'utiliser son propre client. En fait, votre méthode de cryptage des requêtes, en fonction de votre implémentation, peut en fait rendre votre application moins sécurisée en ouvrant des attaques sur d'autres parties du système cryptographique. Votre effort serait mieux dépensé pour essayer de sécuriser les fonctions de l'API elles-mêmes (c'est-à-dire les tester au stylo et les protéger contre des attaques telles que l'injection SQL), plutôt que d'essayer d'empêcher des clients non autorisés d'y accéder.

Mais l'utilisateur utilise déjà votre protocole.

Votre problème est que l'interface de votre serveur de ce que l'utilisateur peut faire n'est pas sécurisée!
Vous décidez quelles données votre serveur envoie à qui!
(Bonjour, chers journaux en ligne. Oui, je vous regarde!)

Concevez-le , en supposant que l'utilisateur est le client. Pas votre code. Parce qu'il l'est. Le client utilisé ne devrait pas avoir d'importance.
Votre application s'exécute sur un processeur sous le contrôle matériel de l'utilisateur. Votre code n'est qu'une liste de commandes / données, et l'utilisateur et son processeur peuvent le traiter comme bon lui semble. Y compris ne pas le traiter.
Il décide de ce que fait son CPU. Ne confondez pas sa grâce d'accepter le code de votre application tel quel avec un droit d'exécution aveugle. C'est vous qui avez confiance ici, et cette confiance est très éphémère.
Surtout avec des tactiques sordides comme celle-ci.

Dans tous les cas: vous donnez à l'utilisateur la clé de cryptage et tout, et l'attendez de ne pas l'utiliser lui-même, car vous le mettez quelque part dans votre panier de code. … Tout comme DRM, c'est de l'huile de serpent et cela ne peut jamais fonctionner.
Il suffit de une personne pour trouver où vous mettez la clé. (Ce serait moi, par exemple.) Tout le monde doit simplement chercher sur Google.

Mais je suis surpris que vous ne pensiez qu'à chiffrer le protocole contre l'utilisateur, au lieu de pour sa protection contre les attaques de type "man-in-the-middle".
En supposant la raison pour laquelle cela est généralement fait (Oui, je vous parle à nouveau de "l'industrie du contenu".): Si votre utilisateur est votre ennemi, peut-être vous devriez rechercher un modèle commercial basé sur l'équité et un gagnant-gagnant, au lieu d'arracher l'utilisateur et d'avoir à faire face à des réactions négatives.

PS: Ignorez toutes les réponses «sécurité par l'obscurité». C'est une erreur qui aboutit à un comportement correct mais qui repose toujours sur des hypothèses invalides. L'utiliser comme argument est, au mieux, amateur et pas vraiment compétent.
En réalité, toute sécurité passe par l’obscurité. Certains sont simplement plus obscurs (= mieux déguisés). La vraie raison pour laquelle cela est mauvais, c'est parce que ce que nous appelons la sécurité réelle est un milliard fois plus obscur, ce qui lui donne une obscurité réelle (statistique) fiable, par opposition à très une simple obscurité qui est trop probable pour que quelqu'un vienne de rien.

Comme d'autres l'ont déjà expliqué, la sécurité par l'obscurité ralentit au mieux un attaquant.

Dans votre cas particulier, je dirais que cela n'aura aucun effet appréciable. Pour arriver à ce stade, votre attaquant devait déjà procéder à une ingénierie inverse de votre application et extraire la clé privée. Cela signifie que votre agresseur n'est pas un idiot et sait ce qu'il fait. Un peu d'obscurité lui coûtera moins de temps qu'il n'en faut pour l'implémenter.

Comme d'autres l'ont déjà mentionné, vous proposez d'utiliser Security by Obscurity. Bien que cette technique ait son objectif, tenez compte des éléments suivants avant de choisir cette approche:

• Fournir un support technique pour votre API. L'utilisation de codes de réponse HTTP trompeurs empêche quiconque d'autre que vous de fournir une assistance. Ils doivent se demander si la situation particulière envoie réellement le code de réponse approprié ou si elle envoie un code obscur. Si vous décidez de rester le seul contact pour toute demande d'assistance, cela ne devrait pas être un problème.
• Qu'est-ce qu'un "utilisateur malveillant"? Soyez prudent lorsque vous catégorisez une demande comme malveillante car elle peut avoir des effets indésirables. Supposons qu'une adresse IP envoie du trafic malveillant et que des contre-mesures soient utilisées. Supposons maintenant que la même adresse IP soit en fait un proxy avec des centaines ou des milliers d'utilisateurs derrière. Vous avez maintenant appliqué votre contre-mesure à tous. Ce même principe peut être appliqué pour identifier les activités malveillantes dans les en-têtes et / ou le corps.
• Le code d'application est le plus lent. La requête doit parcourir toute la pile pour finalement accéder à la logique de «sécurité». Cette architecture ne s'adapte pas bien et est lente. Les demandes incorrectes doivent être arrêtées le plus tôt possible, ce qui est la condition préalable à l'utilisation des pare-feu d'application Web (WAF).
• Extension de l'accès. Si votre API devient accessible à plus de clients que celle pour laquelle elle a été conçue à l'origine, ces nouveaux clients devront être conscients de l'utilisation possible de codes de réponse HTTP trompeurs.
• Utilisateurs malveillants persistants. Comme d'autres l'ont mentionné, cette technique n'est qu'un ralentisseur.

Meilleure approche

Concentrez votre temps sur la liste blanche de toutes les bonnes demandes connues. C'est tellement plus facile que d'essayer d'identifier toutes les mauvaises demandes potentielles. Tout ce qui n'apparaît pas sur la liste blanche devrait immédiatement obtenir un code de réponse approprié tel que HTTP 400 ou HTTP 405 si vous filtrez sur des verbes HTTP (à titre d'exemples). De préférence, cela se produit avant que la demande n'atteigne le code de votre application.

En plus des demandes autorisées pour les listes blanches, assurez-vous que votre application est sécurisée conformément aux Directives OWASP. Vous obtiendrez de bien meilleurs résultats en passant votre temps avec OWASP, puis vous essaierez de déterminer ce qu'est un utilisateur malveillant et de renvoyer un code de réponse HTTP obscur.

Fondamentalement, vous NE POUVEZ PAS empêcher des clients non autorisés d'envoyer des demandes. La chose la plus proche possible serait de faire effectuer une sorte de vérification cryptographique chez le client, mais comme Sherlock Holmes l'a dit, "ce que l'on peut inventer, un autre peut le découvrir". (Je le sais avec certitude, car j'ai piraté la sécurité côté client des gens à plusieurs reprises.)

Au lieu de cela, construisez votre API de telle sorte que quiconque soit autorisé à l'utiliser en utilisant des clients personnalisés. Rendez-le convivial. Que perdez-vous par cela? Les attaquants attaqueront quoi que vous fassiez, et si vous rendez votre API facile à utiliser, quelqu'un proposera quelque chose auquel vous n'avez jamais pensé et rendra votre serveur encore plus grand que vous ne l'auriez jamais imaginé. Que pourrait faire un client qui parle à la fois à votre API et à une autre? Quelles sont les myriades de possibilités et est-ce que cela vous fera vraiment mal de les autoriser?

Je ne ferais pas ça. Cela signifie généralement que vous créez votre propre standard, ce qui fait que:

1. votre API est prédictive après avoir fait une carte de vos réponses http avec leur signification réelle. Changer les réponses HTTP pourrait fonctionner sur certains "hackers" qui abandonneraient après quelques tentatives, mais ce ne sera pas le cas pour d'autres, plus déterminés. Voulez-vous protéger votre API uniquement contre l'ancien type, c'est-à-dire les 11 ans? Je ne pense pas.

2. une certaine confusion pour les développeurs et probablement les testeurs, en particulier ceux qui sont habitués à fonctionner selon les normes mondiales.

3. Choisissez une autre manière. Il y en a certainement quelques-uns. Je me bats moi-même avec le même headscratcher depuis quelques semaines et j'ai trouvé au moins 2 moyens plus ou moins fiables pour obtenir les restrictions souhaitées [je ne peux pas les publier ici].

ol >

Il existe certainement des moyens meilleurs et BEAUCOUP plus efficaces pour obtenir ce que vous voulez. Essayez de regarder votre API sous un angle différent ... Si vous étiez un hacker et que votre vie dépendait du piratage de cette API, que feriez-vous pour réussir? Que devrait-il arriver pour que vous soyez frustré dans vos tentatives de le briser?

Une bonne raison pour ne pas le faire, en particulier pour une application mobile, est qu'il est très probable que votre application communique déjà avec votre serveur via plusieurs proxys, par exemple dans la compagnie de téléphone. La plupart des grandes entreprises utilisent des proxys sur leur réseau pour essayer de protéger leurs systèmes contre le contenu malveillant, et de nombreuses compagnies de téléphone réduisent la qualité des vidéos ou des images en transit. Cela rendra également inutile l'utilisation des différentes bibliothèques système pour HTTP sur votre plate-forme. Une approche couramment utilisée consiste à dériver une clé ou un jeton d'informations que l'utilisateur est peu susceptible de vouloir partager, comme le hachage de son adresse nom et des détails de sa carte de crédit. De cette façon, même si votre application est piratée, les gens hésiteront à donner les informations requises à un programme aléatoire qu'ils ont téléchargé, ce qui limite la capacité de partage de toute attaque éprouvée.

En général, ce n'est pas une bonne idée.

J'en ai fait une utilisation très ciblée une fois avec succès lorsque le site Web d'un client était utilisé par un réseau de blanchiment de cartes de crédit volé. Il y avait des caractéristiques d'identification partagées uniquement par les transactions frauduleuses, donc plutôt que de les refuser poliment, je demanderais au site de retarder la réponse de quelques minutes (personne n'aime un site Web qui prend quelques minutes pour faire quelque chose), puis de renvoyer un 500 avec celui du site. Message standard "désolé, ce n'est pas vous, c'est moi" pour les erreurs de serveur (il a également enregistré des détails à transmettre aux forces de l'ordre). Nous avons eu trois tentatives de transactions qui ont obtenu cette réponse d'opposum et nous n'avons plus jamais entendu parler d'eux.

Mais c'était:

1. En réponse à quelque chose que nous savions être une attaque plutôt que d'être désagréable pour les utilisateurs ayant un problème.
2. Pas une défense contre une attaque contre la sécurité du protocole lui-même, mais au niveau humain au-dessus de cela.
3. Explicable par d'autres explications , c'est-à-dire que nous faisions semblant d'avoir un site Web vraiment nul dans une situation où cela était plausible (il y a beaucoup de sites Web nulles là-bas) et nous n'étions pas une cible spécifique (les perps passeraient à quelqu'un d'autre).

Les utilisateurs ayant un problème devraient être aidés et non abusés. «Je ne peux pas faire ça parce que vous n'êtes pas correctement autorisé» refuse de faire quelque chose de manière utile. "Je ne peux pas faire ça parce que vous devez utiliser un proxy" quand quelqu'un n'a pas besoin d'utiliser un proxy est abusif. Être délibérément inutile n'est approprié que lorsque vous savez que vous êtes attaqué et que cela ne devrait pas ressembler à un message manifestement faux ou que vous n'avez rien caché (vous avez potentiellement révélé quelque chose si le même statut faux n'est pas utilisé pour chaque erreur client).

Cela dit, il est approprié de prendre des mesures pour que les statuts ne fuient pas d'informations. Par exemple. il est acceptable (décrit comme tel dans les normes) pour / admin / à 404 alors que ce serait 200 dans un autre cas (utilisateur autorisé, adresses IP client autorisées, etc.) Alternativement si / members / mon-profil sera de 200 pour un utilisateur autorisé et 403 ou 401 sinon, alors si / members / fdsasafdasfwefaxc ferait 404 pour un utilisateur autorisé, c'est une bonne idée pour 403 ou 401 pour l'utilisateur non autorisé. Il ne s’agit pas tant de la sécurité par l’obscurité que de considérer quels URI se rapportent aux ressources comme l’un des éléments d’information protégés.