HTML/ASP : Masquer le texte de la barre d'état : Cas très particulier - HTML/CSS - Programmation
Marsh Posté le 21-02-2003 à 14:02:40
Nimbus93 a écrit : |
Pourquoi faire ?
Citation : |
Pourquoi faire ?
Si c'est pour des raisons décoratives, ce sont de mauvaises raisons. Et si c'est pour des raisons de sécurité, il n'existe aucune solution sécures pour ton problème.
Marsh Posté le 21-02-2003 à 15:25:41
Hermes le Messager a écrit : |
C'est un peu long à expliquer mais si ca interesse vraiment je peux donner des détails, mais derrière il y a des appels pour une partie publique du site et des appels similaires pour une partie privée du site.
Le but du jeux est de cacher les paramètres envoyés aux pages ASP de manière à ce qu'un petit malin ne devinne pas comment accéder à la partie privée.
Ainsi l'URL reste fixe on ne voit pas quelles sont les pages ni les arguments qui tournent derrière. Voilà pour la petite histoire, ca ca marche.
Hermes le Messager a écrit :
|
Pour les mêmes raisons : lorsque tu passes sur le lien on voit les arguments passés aux pages ASP, donc retours à la case départ.
Hermes le Messager a écrit : |
Non à la déco, oui à la sécurité. Il ya tjs une solution à tout problème. Le problème c'est de trouver laquelle
Marsh Posté le 21-02-2003 à 15:35:35
Nimbus93 a écrit : |
Marsh Posté le 21-02-2003 à 15:41:21
Nimbus93 a écrit : |
Tu peux oublier le fait de dissimuler les paramètres passés dans l'url.
Ta méthode est mauvaise. Point barre, rien à ajouter. Si tu ne nous crois pas, tu peux demander ailleurs...
Marsh Posté le 22-02-2003 à 08:59:05
pour cacher les paramètres, ce n'est pas mieux de les passer par formulaire?
j'aimerais savoir votre avis là-dessus car j'utilise le formulaire quand je ne veux pas qu'on puisse voir les paramètres importants.
Marsh Posté le 22-02-2003 à 09:45:05
Nimbus93 a écrit : |
les gens assez malins pour faire ça vont vite désactiver le JS et virer ta frame
deux clics dans un browser style Mozilla/Opera
Marsh Posté le 22-02-2003 à 09:46:05
Urd-sama a écrit : pour cacher les paramètres, ce n'est pas mieux de les passer par formulaire? |
suffit de regarder le source, et à la limite éditer la page en local, et l'utiliser en local pour faire ensuite le POST vers le serveur.
À mon avis les sessions c'est nettement plus sûr
Marsh Posté le 22-02-2003 à 14:48:45
antp a écrit : |
ouais pas con... bon faut etre paticulièrement vicieux pour faire ca quand meme
Marsh Posté le 22-02-2003 à 15:48:33
Urd-sama a écrit : |
Bof...
Je rejoins ANT. Il vaut 100 fois mieux utiliser les sessions. (Et même comme ça, on est pas toujours à l'abri )
Marsh Posté le 23-02-2003 à 00:22:42
Euh je veux bien admettre que j'suis un peu newbie en développement web et je veux pas KC l'ambiance mais vous avez tout faux là y'm semble bien les gars !
Le code c'est de l'ASP ! et l'ASP ca génère du HTML en source au niveau serveur pas client ! Donc quand tu vas regarder la source de la page t'auras nada d'interessant, tu sera pas avancé et t'auras Zéro éléments pour connaitre les paramètres et le contenu du code ASP (encore heureux !)
Pour antp, évidemment éditer la page ASP en local t'as le source ! Mais si une page ASP peut se lire en local (jusque là tout va bien) elle ne s'execute qu'au niveau du serveur. Donc niet !
Donc tout faux !!!
PS : évidemment j'utilise les sessions mais je vois pas le rapport avec la problématique !
Marsh Posté le 23-02-2003 à 00:41:23
Nimbus93 a écrit : |
bhen oui prends moi pour un con tant que t'y es
je répondais à Urd-sama qui parlait de champs cachés dans la page, qui seraient rendus au serveur via POST.
Ces champs sont du HTML pur, donc ça fait partie de ce qu'a le client, donc modifiable, donc pas sûr si aucun contrôle n'est fait côté serveur.
Marsh Posté le 23-02-2003 à 01:10:58
antp a écrit : |
Ben je répondais à ça
Marsh Posté le 23-02-2003 à 01:27:17
Nimbus93 a écrit : |
Alors je vois vraiment pas ce que ASP a à voir là dedans, puisque je répondais au truc du javascript et de la frame
Marsh Posté le 23-02-2003 à 05:31:00
antp a écrit : |
+1
Marsh Posté le 23-02-2003 à 22:24:07
Ok pour le JS et la frame, de toute façon on voit le chemin de la page ASP a appeler en éditant la frame...
Bon alors y'a pas de soluce, on peut rien masquer ?
Marsh Posté le 23-02-2003 à 22:50:27
bon, bin, tu peux "cacher" ce qui s'affiche dans la barre d'etat, mais le nom de la page asp et celui des parametres qu'elle recoit étant fourni au client, l'homme derriere l'ordi peut lire ça sans probleme.
si tu y tiens vraiment, <a href="mapage.asp" onmouseover="parent.status='';return true;"> regle ton probleme...sauf si le gars desactive javascript ou lit le source coté client. Si tu recherches la securité, c'est bien mince...
l'est où ton site que je teste ?
Marsh Posté le 24-02-2003 à 00:03:46
Nimbus93 a écrit : Euh je veux bien admettre que j'suis un peu newbie en développement web et je veux pas KC l'ambiance mais vous avez tout faux là y'm semble bien les gars ! |
je voulais juste quoter, désolé et mettre en parallèle avec ce que tu avais dis juste avant
Nimbus93 a écrit : |
Marsh Posté le 24-02-2003 à 00:21:25
Nimbus93 a écrit : Le but du jeux est de cacher les paramètres envoyés aux pages ASP de manière à ce qu'un petit malin ne devinne pas comment accéder à la partie privée. |
Si le petit malin veut te nuire, il n'aura aucun mal à contourner ces artifices de protection. Et si tu fondes ta sécurité sur ces seuls artifices, ton site est en danger.
Ton modèle de sécurité est complètement à revoir. Désolé
Marsh Posté le 24-02-2003 à 00:23:35
marrant on dirait Yvele. Il prétend qu'il peut y arriver mais en même temps il dit qu'il est newbie.
Toute façon si je décide d'intercepter toute communication entre mon browser et ton site, rien ni personne ne peut m'en empêcher tiens.
En plus d'après ce que tu dis, j'en conclus que les données sensibles pour la partie privée de ton site sont dans la page web. Donc pour intercepter ces données c'est piece of cake
edit: aie grillé par gm
Marsh Posté le 24-02-2003 à 00:33:40
gm_superstar a écrit : |
et pendant ce temps, utilisabilité = 0
Marsh Posté le 24-02-2003 à 08:03:58
Marsh Posté le 24-02-2003 à 08:50:55
énorme ce topic
Marsh Posté le 24-02-2003 à 09:42:25
Harkonnen a écrit : énorme ce topic |
ça dépend, ya des newbies qui croient vraiment ce qu'ils disent. Mais quand même chuis d'accord
Marsh Posté le 24-02-2003 à 13:20:52
Z'êtes enragés ce matin les gars !!!
Je vois pas le rapport entre être newbie en programmation de pages web et vouloir bien faire en terme de sécurité. Si je poste c'est bien pour avoir l'avis des habitués. Mais bon.
Donc le modèle de protection est mauvais. ArF Dur !
Vous fatiguez pas à vouloir me démontrer que vous êtes les meilleurs et que patati patata j'vous crois les gars. Pour préciser les choses ca va pas être si facile que ça de venir tester le merdier, puisqu'il s'agiut de toute façon d'un intranet !!!
Donc déjà faut venir jusque là !
Les données "privée" ne sont pas si sensible que ça, mais ne s'adresse pas forcemment au même public. Le niveau de sécurisation n'a donc pas besoin de ressembler à celui de Fornox (tiens comment ca s'écrit ca au fait ?) .
Le public à qui ces informations sont adressé n'est pas forcemment non plus des plus avertis.
Cela étant, je vois pas pourquoi je me priverais de faire bien et de vouloir sécuriser un max. Donc au lie d'essayer de me Kc, feriez-mieux m'aider
PS : JE précise que vos reflexions me font bien marrer tout de même (j'ai de l'humour)
Marsh Posté le 24-02-2003 à 13:21:54
thesmilingface a écrit : bon, bin, tu peux "cacher" ce qui s'affiche dans la barre d'etat, mais le nom de la page asp et celui des parametres qu'elle recoit étant fourni au client, l'homme derriere l'ordi peut lire ça sans probleme. |
Ca ca marche en HTML pas avec mon format de page ASP.
Marsh Posté le 24-02-2003 à 13:29:03
Nimbus93 a écrit : Z'êtes enragés ce matin les gars !!! |
Très bien, dans ce cas là, évites de leur donner des leçons.
Citation : Donc le modèle de protection est mauvais. ArF Dur ! |
Ouaiiii, il a compris. ça fait 20 messages qu'on te le répette.
Citation : |
1) Fallait préciser au départ. 2) De plus, qu'est-ce que t'en a à foutre de la sécu à ce moment là ? Tu bosses dans une banque ou quoi ? Vous avez des pirates chez vous ?
Citation : Les données "privée" ne sont pas si sensible que ça, mais ne s'adresse pas forcemment au même public. Le niveau de sécurisation n'a donc pas besoin de ressembler à celui de Fornox (tiens comment ca s'écrit ca au fait ?) . |
Citation : Le public à qui ces informations sont adressé n'est pas forcemment non plus des plus avertis. |
écris un peu mieux STP, ça reposera tout le monde.
Citation : |
Quand on cherche à t'aider, tu nous explique que les pages en ASP ne sont pas visibles par IE. Tu nous prends pour des cons, et après tu t'étonnes d'avoir ce genre de réactions ? Moi je trouve que tu es tombé dans un bon jour plutôt... D'autres que toi se sont retrouvés dans le BEST OF pour moins que ça.
Citation : PS : JE précise que vos reflexions me font bien marrer tout de même (j'ai de l'humour) |
C'est toi qui nous fait marrer. Espèce de boulet va...
Marsh Posté le 24-02-2003 à 13:30:20
> Fort Knox
voilà tu sais maintenant
pis dis, on se prend pas pour Dieu le père hein. Tu as voulu un avis, on te l'a donné. Et on t'a aussi dit qu'il n'y avait pas de sécurité absolue, c'est un fait, et ce n'est pas seulement valable que pour le web. On voulait seulement te le faire remarquer
Et tu peux effectivement pas empêcher quelqu'un de voir le source de la page, ne fusse que via le cache de ton browser ou via un View Source des familles, c'est très facile. Il existe seulement certains modèles de sécurité meilleurs que d'autres. Il en existe sans doute un meilleur que tous les autres, mais aucun qui soit 100% garanti. Voilà.
Marsh Posté le 24-02-2003 à 13:36:45
Hermes le Messager a écrit : |
il y est maintenant
Marsh Posté le 24-02-2003 à 13:37:49
Hermes le Messager a écrit :
|
Prend un lexomil vieux, je viens chercher de l'aide, et contrairement à tes interventions de "Mr le maître du monde" je ne me permet pas de donner de leçons à quiconque, mais juste d'essayer de faire avancer les choses.
Si t'as rien de plus constructif à dire abstiens-toi et va polluer le forum bla-bla !
Tu ferais mieux de démontrer ta science puisque t'es si fort plutôt que faire-valoir tes acquis en grossièretés !
Marsh Posté le 24-02-2003 à 13:41:16
drasche a écrit : > Fort Knox |
Merci
drasche a écrit : |
Jusque là j'suis d'accord, je sollicite un avis, voius me le donnez et je le prend bien volontiers, merci.
Je sais bien qu'il n'y a pas de solution infaillible, j'suis pas newbie dans tous les domaines, j'ai déjà quelques années de pratique derrière moi, mais raison de plus pour trouver la meilleure solution à défaut d'être parfaite.
Marsh Posté le 24-02-2003 à 13:46:55
Nimbus > ne t'inquiète pas, je commence à avoir l'habitude de cette bande de charlots ! Tu n'imagines pas le nombre de fois ou j'ai du me débrouiller parce que cette bande d'incapables m'a pris de haut !
Ce que je te conseille de faire : tu utilises un proxy, que tu blindes via un firewall dédié sur le port 67847, ce qui fait que l'IP de loopback sera bloquée à cause du transfert asynchrone du au fait que le port 67847 ne peut être normalement adressé, car la plage des ports se fait sur 16 bits alors que tu travailles en 32 bits, ce qui te permet de simuler un pseudo-port qui fera que le hacker en herbe se retrouvera devant une 404.
J'entends ta question : si j'utilises le port 67847, n'y a t'il pas un risque que la couche interne du TCP/IP ne me sorte une "fatal socket exception" à cause du fait que ce port est normalement utilisé par les datagrammes d'accés aux données d'entrées du serveur principal (qui est un proxy si tu te souviens bien) ?
En fait, tu n'as pas tout à fait tort, mais tu as oublié que nous sortons ici de la plage de validité des ports (qui ne dépasse pas 16 bits, tu te souviens ?). Dans ce cas, les 2 octets de poids faibles servant à la restranscription du port sont masqués et inaccessibles de l'extérieur.
N'hésite pas à me contacter si tu as le moindre doute.
Marsh Posté le 24-02-2003 à 13:50:59
Marsh Posté le 24-02-2003 à 13:51:31
NB : Il va de soi que cette solution ne fonctionne que si le browser web est basé sur un moteur Gecko
Marsh Posté le 24-02-2003 à 16:15:08
Serial Coder a écrit : NB : Il va de soi que cette solution ne fonctionne que si le browser web est basé sur un moteur Gecko |
puis faut que le browser ai le plugin pour gerer l'ASP!
...
Marsh Posté le 24-02-2003 à 16:20:03
Serial Coder>
Cool
J'avais pas pensé à cette solution.
Nimbus93> prends-en de la graine
bon, bin serieusement, l'ASP, c'est un langage qui écrit du html.
Sa force réside dans la manipulation de variables ASP (non accessible sauf si mr tout le monde a un acces physique au serveur) et de base de donnees (non accessible, sauf si tu colles un post-it sur l'ecran du serveur pour t'en rappeler le mot de passe)
Comprend bien que tout ce qui s'affiche sur le navigateur est en html, javascript et non pas en ASP.
Marsh Posté le 24-02-2003 à 16:35:11
Mr yvele a écrit : |
Marsh Posté le 21-02-2003 à 12:52:50
Salut !
Pour masquer le texte de la barre d'état pour tous les liens d'une page, il ya plusieurs possibilités. On peut par exemple utiliser ce script :
<script>
//Hide status bar msg II script- by javascriptkit.com
//Visit JavaScript Kit (http://javascriptkit.com) for script
//Credit must stay intact for use
function hidestatus(){
window.status=''
return true
}
if (document.layers)
document.captureEvents(Event.MOUSEOVER | Event.MOUSEOUT)
document.onmouseover=hidestatus
document.onmouseout=hidestatus
</script>
Seulement voilà y'a un cas ou ca marche po ! J'utilise un fichier HTML avec une frame invisible, de manière à ce que l'URL reste toujours la même et qu'on ne voit pas l'architecture du site.
C'est donc dans le contenu de la frame qui change. Histoire de faire simple ( ) ce sont des pages ASP que je charge dans cette frame.
Dans ce cas particulier, tous les liens sont visibles, puisque c'est la génération de la page ASP qui le permet.
Il me faudrait donc soit une solution au niveau de la page HTML qui contient la frame, soit masquer le contenu de la barre d'état par de l'ASP.
Le code complet de ma page HTML defaut.htm :
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<script>
//Hide status bar msg II script- by javascriptkit.com
//Visit JavaScript Kit (http://javascriptkit.com) for script
//Credit must stay intact for use
function hidestatus(){
window.status=''
return true
}
if (document.layers)
document.captureEvents(Event.MOUSEOVER | Event.MOUSEOUT)
document.onmouseover=hidestatus
document.onmouseout=hidestatus
</script>
<frameset cols="0,*" border=0>
<frame src="">
<frame src="default.asp">
</frameset>
</head>
<body bgcolor="#FFFFFF">
</body>
</html>