Comment insérer du javascript dans une URL?
Duplicate of:
C'est une question de sécurité.
Que dois-je rechercher dans l'URL qui empêche le piratage?
Existe-t-il un moyen d'exécuter javascript en le passant à l'intérieur d'une URL?
Comme vous pouvez le constater, ce concept est relativement nouveau pour moi.
Des bons messages sur ce genre de choses?
Je ne crois pas que vous puissiez pirater via l'URL. Quelqu'un pourrait essayer d'injecter du code dans votre application si vous transmettez des paramètres (GET ou POST) à votre application, de sorte que votre évitement sera très similaire à ce que vous feriez pour une application locale.
Assurez-vous de ne pas ajouter de paramètres à SQL ou à d'autres exécutions de script passées dans le code à partir du navigateur, sans vous assurer que les chaînes ne contiennent aucun langage de script. Recherchez dans la suite des informations sur les attaques par injection pour la plate-forme de développement sur laquelle vous travaillez, qui devraient fournir de nombreux bons conseils et exemples.
vieille question dans laquelle j’ai trébuché et qui, à mon avis, mérite une mise à jour ... Vous pouvez en fait exécuter du javascript à partir de l’URL, et vous pouvez aussi faire preuve de créativité. J'ai récemment créé une zone réservée aux membres, dans laquelle je souhaitais rappeler à quelqu'un le mot de passe correspondant. Je recherchais donc une alerte non locale. Bien sûr, vous pouvez intégrer une alerte à la page elle-même, mais ensuite à son public. La différence ici est que je peux créer un lien et glisser du JS dans le href afin que cliquer sur le lien génère l'alerte.
voici ce que je veux dire >>
<a href="javascript:alert('the secret is to ask.');window.location.replace('http://google.com');">You can have anything</a>
et ainsi en cliquant sur le lien, l'utilisateur reçoit une alerte avec les informations, puis ils sont pris à la nouvelle page.
vous pouvez évidemment aussi écrire un onClick, mais le href fonctionne très bien lorsque vous le glissez dans l'URL, n'oubliez pas de le préfixer avec "javascript:"
* fonctionne en chrome, ne vérifie rien d'autre.
Javascript peut être exécuté sur la page actuelle en le mettant simplement dans l'adresse URL, par exemple.
javascript:;alert(window.document.body.innerHTML);
javascript:;alert(window.document.body.childNodes[0].innerHTML);
Javascript dans l'URL ne sera pas exécuté seul. Cela ne signifie en aucun cas qu'il est sûr ou fiable.
Une URL est une autre entrée d'utilisateur non digne de confiance; GET ou POST (ou toute autre méthode) peut entraîner de nombreuses vulnérabilités graves.
Un exemple courant était/est l'utilisation des variables PHP_SELF, REQUEST_URI, SCRIPT_NAME et similaires. Les développeurs les renvoyaient par erreur directement au navigateur, ce qui avait conduit à l'injection du script dans la page et à son exécution.
Je vous suggère de commencer à lire beaucoup, voici quelques bons endroits pour commencer:
Consultez également Google pour XSS (script intersite), XSRF (falsification de requête intersite) et SQL Injection. Cela vous aidera à démarrer, mais il faut rassembler beaucoup d’informations, prenez donc votre temps. Cela en vaudra la peine à long terme.
Cela dépend de votre application et de son utilisation, ainsi que du niveau de sécurité dont vous avez besoin.
En termes de sécurité, vous devez valider toutes les valeurs que vous obtenez des paramètres de chaîne de requête ou de publication, afin de vous assurer de leur validité.
Vous pouvez également souhaiter ajouter une journalisation pour les autres, y compris une analyse des blogs, afin de pouvoir déterminer si une tentative de piratage de votre système est en cours.
Je ne crois pas qu'il soit possible d'injecter du javascript dans une URL et de l'exécuter, à moins que votre application utilise des paramètres sans les valider au préalable.
Je crois que la bonne réponse est "ça dépend".
Comme d'autres l'ont souligné, si l'application Web qui traite votre demande reçoit et renvoie en écho les paramètres de charge utile ou d'URL reçus (pour les demandes GET), elle peut être soumise à une injection de code.
Toutefois, si l'application Web assainit et/ou filtre la charge utile/les paramètres, cela ne devrait pas poser de problème.
Cela dépend également de l'agent utilisateur (navigateur, par exemple), un agent utilisateur personnalisé peut injecter du code sans notification de l'utilisateur s'il en détecte une dans la demande (je ne connais pas de code public, mais c'est également possible).
La clé consiste à examiner toutes les informations que vous recevez, puis à afficher et/ou à utiliser en code sur le serveur. Les variables de formulaire Get/Post si elles contiennent du javascript que vous stockez et que vous réaffichez ultérieurement constituent un risque pour la sécurité. De même que tout ce qui est concaténé sans être examiné dans une instruction SQL que vous exécutez.
Un potentiel à surveiller est celui des attaques qui dérangent le codage des caractères. Par exemple, si je soumets un formulaire avec un jeu de caractères utf-8 mais que vous enregistrez et que vous affichez ensuite en latin iso-8859-1 sans traduction, je pourrais peut-être passer quelque chose devant votre validateur. La façon la plus simple de gérer cela consiste à toujours afficher et stocker dans le même jeu de caractères. utf-8 est généralement un bon choix. Ne comptez jamais sur le navigateur pour faire le bon choix pour vous dans ce cas. Définissez des jeux de caractères explicites, examinez les jeux de caractères que vous recevez et effectuez une traduction vers le jeu de stockage attendu avant de le valider.
L'injection de JavaScript n'est pas une attaque contre votre application web. L'injection JavaScript ajoute simplement du code JavaScript pour que le navigateur s'exécute. La seule manière dont JavaScript pourrait nuire à votre application Web est si vous publiez un blog ou un autre domaine dans lequel les entrées de l'utilisateur sont stockées. Cela pourrait être un problème, car un attaquant pourrait injecter son code et le laisser là pour que d'autres utilisateurs l'exécutent. Cette attaque est connue sous le nom de Cross-Site Scripting. Le pire des scénarios serait une falsification sur plusieurs sites, qui permet aux attaquants d’injecter une déclaration qui va voler le cookie d’un utilisateur et donc lui donner son identifiant de session.