L'open-source le code d'une webapp n'est-il pas recommandé?
Comment savoir dans quel langage de programmation un site Web est intégré?
Et d'autres Q comme ceux-ci ^.
En bref: il semblerait qu'au moins en termes de développement d'applications Web, nous souhaitons divulguer le moins d'informations possible à l'attaquant.
- Les attaquants veulent déterminer la plate-forme sur laquelle notre application Web fonctionne, mais nous voulons leur faire croire qu'il s'agit d'une plate-forme différente de ce qu'elle est réellement;
- Il est conseillé de désactiver le mode de débogage, car des informations détaillées sur les exceptions peuvent divulguer des parties du code source de notre application (pas celle de la plate-forme);
Si nous open-source le code serveur de notre application web, nous remettons volontiers à chacun ces mêmes informations que les questions que j'ai liées pour discuter comment cacher ; et encore plus d'informations que cela.
Il semblerait donc que l'application open-source soit l'une des dernières choses que l'on voudrait faire.
Cela m’étonne car:
- Certains pensent que les applications open source sont plus sûres car des yeux plus amicaux peuvent regarder le code, rechercher des bogues exploitables et soumettre des correctifs;
- L'open-sourcing de l'application en raison des problèmes susmentionnés est la sécurité par l'obscurité, ce qui est mauvais.
Cependant, selon @ Commentaire de Mason Wheeler sur ce site :
Je pense que, même si un testeur de sécurité ne peut pas comprendre dans quelle langue le site est intégré, cela le rend plus sécurisé car personne ne saura quels exploits essayer. (Oui, il existe parfois des cas d'utilisation valides pour la sécurité par l'obscurité.)
Par conséquent, est-il convenu que l'open source du code côté serveur d'une application Web est une idée horrible?
C'est une question complexe car il y a plusieurs aspects à considérer, avec des avantages et des inconvénients, et il n'y a peut-être pas de réponse définitive.
L'avantage de sécurité des logiciels open source est censé provenir d'une "loi" que Wikipedia appelle "la loi de Linus", qui dit que "étant donné suffisamment de globes oculaires, tous les bogues sont superficiels". Pour commencer, vous devez vous demander combien de globes oculaires vous allez avoir. Par exemple, votre projet sera-t-il partagé, bifurqué, largement utilisé par de nombreux utilisateurs et examiné par une large communauté? Ou votre logiciel ne sera-t-il utilisé que sur votre site Web et personne d'autre ne s'en souciera? Ou peut-être que personne d'autre ne pourra le réutiliser car il ne vient pas avec une licence de logiciel libre? En fin de compte, il y aura des globes oculaires à chapeau blanc et des globes oculaires à chapeau noir, vous devez donc être prêt à accepter que d'une part, vous obtiendrez une amélioration de la sécurité des pirates éthiques, mais d'autre part, vous serez également attaqué par des chapeaux noirs. Les attaquants seront-ils particulièrement intéressés à cibler votre projet, ou va-t-il simplement faire l'objet d'attaques non ciblées? Ce sont toutes des choses que vous devriez considérer, et il pourrait ne pas être facile de tirer une conclusion. Il convient également de rappeler que dans plusieurs projets open source, il y avait des failles de sécurité qui existaient depuis longtemps malgré tous les globes oculaires de la communauté (voir Loi de Linus sur Wikipédia).
La sécurité par obscurité est un autre concept souvent mal compris, car son nom donne l'impression qu'il s'agit de garder quelque chose de secret. Ce n'est pas le cas. La sécurité par l'obscurité se produit lorsqu'une partie importante de votre sécurité provient du secret des méthodes (l'implémentation). Voici un exemple de sécurité par obscurité:
// Login without password if URL has parameter dev=debug
// I'm a stupid dev, so I believe this is secure because nobody knows about it!
// But this source code can't be published or I'll be hacked at once
if ($login_password === $password || $_POST['dev'] === 'debug') {
login_ok();
}
Quoi qu'il en soit, même si votre code est correct et que vous comptez sur la sécurité dès la conception, rien ne vous empêche d'utiliser une couche d'obscurcissement par-dessus. Autrement dit, garder le code source privé peut vous aider car cela ralentira un attaquant potentiel. La chose importante à retenir est que l'obscurité est correcte et ne peut être considérée comme un grand atout que si elle est juste une couche au-dessus d'une bonne conception.
En conclusion, je dirais que vous feriez mieux de ne pas publier le code source sauf si vous avez une raison de le faire (par exemple parce que vous voulez que votre logiciel soit gratuit/libre et que vous souhaitez créer une communauté autour de votre projet). Si votre seul objectif est d'améliorer la sécurité de l'application, vous ne gagnerez rien en la publiant simplement sur GitHub, par exemple. Si vous êtes vraiment inquiet que votre logiciel puisse contenir des erreurs et que vous souhaitez que quelqu'un d'autre vous aide en fournissant plus de "globes oculaires", vous pourriez envisager de payer pour un audit de sécurité professionnel.
Il est important de lire ce que j'ai écrit dans son contexte.
Oui, il existe parfois des cas d'utilisation valides pour la sécurité par l'obscurité.
Cela a été écrit en réponse à une question sur les tests de pénétration d'un système de boîte noire, où l'idée que la source soit disponible n'était même pas sur la table. Dans un tel cas, la sécurité par obscurité peut avoir une certaine utilité. En règle générale, cependant, ce n'est pas particulièrement utile, et quand c'est le cas, il n'est utile que comme partie unique d'une stratégie de défense en profondeur plus large. Vous ne pouvez pas attaquer une cible si vous ne savez pas où elle se trouve, mais une fois que le méchant sait ce qu'il vise, vous feriez mieux d'avoir également d'autres défenses en place ou vous allez être en haut ruisseau proverbial.
Aussi - et plus applicable à cette question que considère la possibilité d'ouvrir le code source - quels que soient les avantages que vous pourriez retirer de masquer les sources, largement compensé par Principe de Kerckhoff : "[vous devez toujours supposer que] l'adversaire connaît le système." En d'autres termes, si vous ne pouvez pas considérer votre système comme sûr si l'adversaire a le code source complet, vous ne pouvez pas le considérer comme sûr, point final. (Ce qui est juste du bon sens; dans quelle mesure feriez-vous confiance à un verrou physique où la quincaillerie vous a dit qu'il était important de le cacher pour que les gens ne voient pas de quel type de verrou il s'agit?)
Si vous commencez avec l'hypothèse que l'adversaire connaît le système - ce qui, dans le monde réel, signifie qu'il peut avoir acquis cette connaissance par le biais d'autres piratages, par une forme d'espionnage ou divers autres compromis - alors il s'ensuit logiquement que la publication le code ne lui apprend rien de nouveau. Ce qu'il fait, c'est donner aux bons la possibilité de se rattraper: les honnêtes gens qui n'essaieraient jamais de vous pirater ou de compromettre votre sécurité sont maintenant invités à jeter un œil et à indiquer les endroits où cela pourrait être mieux.
Du point de vue strictement de la cybersécurité, la publication de la source l'emporte clairement sur l'obscurité. Il peut y avoir d'autres raisons de ne pas vouloir le faire (protection des méthodes commerciales ou d'autres informations sensibles), mais être meilleur pour empêcher les pirates informatiques de sortir n'est pas l'une d'entre elles.
La sécurité par l'obscurité n'est pas une mauvaise chose, elle n'est tout simplement pas fiable. Cela ne devrait jamais être votre principale ou unique méthode pour protéger quelque chose. Cela peut être trompeur et illusoire. Mais il a encore une certaine valeur, en plus d'autres méthodes. Ne pas connaître votre plate-forme pourrait ralentir un attaquant ou lui faire rater d'éventuelles voies d'attaque. D'autant plus que l'inverse s'applique, il existe des outils de stylo-test pré-écrits qui appliquent les vulns connus les uns après les autres. Pourquoi risquer de les exposer?
L'approche des "yeux amicaux" fonctionne pour Linux parce que beaucoup de gens utilisent réellement Linux, et ont un intérêt pour son fonctionnement continu et amélioré. Même chose avec Apache et quoi que ce soit d'autre. Ce n'est probablement pas le cas pour votre application Web. Vous développez probablement votre application Web pour une utilisation spécifique de votre propre entreprise plutôt qu'un cadre plus général que n'importe qui pourrait intégrer à son site. Il est donc peu probable que vous profitiez de contributeurs.
Obscurcissez-les! Et aussi tous les autres trucs appropriés aussi.
Il y a une différence importante entre publier votre code et ne pas protéger votre code contre un accès par un exploit.
Si vous publiez votre code, il y aura des blackhats, greyhats et whitehats avec accès à votre code. Les whitehats divulgueront toutes les vulnérabilités qu'ils découvrent, et les greyhats peuvent les divulguer si la prime de bogue est suffisamment importante. Les Blackhats essaieront de vous pirater quoi qu'il arrive, et le code publié les aidera, il y a donc un compromis à faire entre l'avantage que vous retirez des vulnérabilités divulguées et le danger que les attaquants découvrent des vulnérabilités. Mais ce compromis favorise souvent la publication.
Si votre code est découvert par un exploit, ce seront surtout les blackhats qui y auront accès. Si des vulnérabilités sont découvertes de cette façon, il y a beaucoup moins de chances qu'elles soient divulguées de manière responsable, il est donc très peu probable que ce compromis fonctionne en votre faveur.
J'ai développé plusieurs projets open source dont Digitalus CMS 2007-2012. Maintenant que nous avons des outils de construction comme NPM, je préfère une approche où je partage des modules spécifiques et plus génériques, pour lesquels il serait presque impossible de revendiquer la propriété intellectuelle, puis de garder la mise en œuvre finale privée.
Cette approche est plus facile à adopter pour un plus large éventail de projets et vous offre l'avantage d'avoir des milliers de regards sur vos bibliothèques principales tout en vous permettant de protéger votre application principale.