2012-02-22 6 views
2

J'ai un partenaire de confiance que je veux lui permettre d'appeler mon Iframe et ajouter un chemin de fichier JS/CSS en tant que paramètre et je vais l'appeler comme ça:Appeler un JS externe et CSS sur mon site - Quel est le risque

<script type="text/javascript" src="@(HttpUtility.UrlDecode(HttpContext.Current.Request.Params["CustomJs"]))" ></script> 
<link type="text/css" media="screen" href="@(HttpUtility.UrlDecode(HttpContext.Current.Request.Params["CustomCss"]))" rel="stylesheet" /> 

Ceci est dans le but de lui permettre d'accrocher la conception et d'enregistrer certains crochets JS. Le partenaire est digne de confiance et signera sur un document que l'utilisation du JS/CSS est seulement pour les fonctions autorisées qui seront appelées de notre côté. La question est, est-ce que j'expose mes clients à une situation dangereuse de toute sorte (en supposant que les partenaires sont OK).
tout est sous SSL
Quel est le risque de sécurité.

Merci

+0

Le code que vous avez posté est le document qui est chargé dans le cadre, n'est-ce pas? – Gumbo

+0

@Gumbo, oui c'est – SexyMF

Répondre

1

Depuis le CSS et JavaScript sont intégrés dans le document dans un cadre et non directement dans votre document, le CSS est uniquement appliquée au document du cadre.

Si le JavaScript du cadre peut accéder au DOM de votre document est un peu plus compliqué. Car ici, le Same Origin Policy est appliqué. Mais à moins que vous et votre partenaire ne partagent la même origine, le JavaScript de votre partenaire ne peut pas accéder au DOM de votre document et en lire les données ou le modifier.

2

Le risque est que si la sécurité de votre partenaire est compromise, votre système deviendra également non sécurisé. Hypothétiquement, si un attaquant ajoute un code malveillant aux scripts de votre partenaire, le code peut être transmis à votre système. Ceci est fortement lié aux attaques de script intersite http://en.wikipedia.org/wiki/Cross-site_scripting.

Afin de contourner ce risque, je recommande d'implémenter un proxy modéré pour ces fichiers JS/CSS. Par exemple, un gestionnaire ASP.NET (.ashx) qui appelle le site du partenaire pour les scripts originaux et les stocke quelque part en interne (peut-être dans une base de données), alors que le cadre en question utilise les scripts et CSS via handler. Quelque chose comme:

<script ... src="ModeratedProxy.ashx?partner=abcd&file=efg.js"></script> 

Le gestionnaire avisait le propriétaire du site si les scripts change partenaire, et peut même permettre de pré-modération de tous les fichiers externes.

+1

Vous avez donc identifié un risque très réel pour l'affiche originale (OP). Que diriez-vous de faire un swing à la façon dont il peut accomplir son objectif? Méthodes pour répondre à la même politique d'origine? Créer une sorte de page de proxy à l'hôte d'origine afin que le partenaire de confiance puisse mélanger les données js/css via l'hôte? – EBarr

+0

@EBarr, merci d'avoir encouragé la discussion. Afin de contourner ce risque, je recommande d'implémenter un proxy modéré pour ces fichiers JS/CSS. Par exemple, un gestionnaire ASP.NET (.ashx) qui appelle le site du partenaire pour les scripts originaux et les stocke quelque part en interne (peut-être dans une base de données), alors que le cadre en question utilise les scripts et CSS via handler (' '). Le gestionnaire avertit le propriétaire du site si le partenaire modifie les scripts et peut même autoriser la modération préalable de tous les fichiers externes. –

Questions connexes