Pagina omleiden

Status
Niet open voor verdere reacties.
B

bgandalf

Gebruiker
Lid geworden
4 mrt 2010
Berichten
5
Hallo allemaal,
Ik heb het volgende probleem waar ik niet uit kom:

Ik heb een pagina gemaakt die beveiligd is met een Gebruikersnaam en Wachtwoord. Let wel, niet vanuit een database of zoiets maar gewoon in html code. Het systeem is gebaseerd op GateKeeper maar dan verfijnder!

De website bestaat uit frames en om te voorkomen dat een pagina los opgeroepen kan worden heb in elke pagina het volgende javascript staan:

<SCRIPT LANGUAGE="JavaScript">
<!-- Hide script
if ( top.location == self.location ) {
top.location.href = "http://www.een domeinnaam.nl/";
}
//-->
</SCRIPT>

Oftewel, als een pagina direct aangeroepen wordt dan zal de bezoeker naar het start adres gestuurd worden. Dus: "http://www.een domeinnaam.nl/"

En dat is wat we willen! Toch :eek:

Om te voorkomen dat het HistoryBack systeem van de internet browser werkt wordt de beveiligde pagina buiten de frames opgeroepen. Zo weet ik namelijk zeker dat na het sluiten van de beveiligde pagina geen historie in de browser achter blijft!

Dit heeft echter tot gevolg dat bovenstaand javascript de bezoeker altijd terug zal sturen naar "http://www.een domeinnaam.nl/". Als ik het javascript verwijder dan is de pagina weer direct oproepbaar!! En dat wil ik niet!

Ik ben nu al weken bezig om dit op te lossen maar ik kom er niet meer uit, draai in dezelfde cirkel rond en loop steeds weer vast.

Wat ik eigenlijk wil is dat het oproepende "htm" bestand (menu.htm) iets meegeeft aan de beveiligde pagina. Ontbreekt dit.... dan terug naar "http://www.een domeinnaam.nl/"

Is er iemand die een mooie oplossing weet.

Met dank en in afwachting van...
 
Javascript is geen beveiliging. Je kunt het namelijk gewoon uitzetten en dan heb je alsnog toegang.

Wat je zoekt is óf een serverside oplossing (PHP en eventueel SQL) of een .htauth file met een naam en wachtwoord.

Als je bij Javascript en HTML blijft krijg je het nooit veilig.
 
Hallo Frats,

Dit was niet de vraag die ik stelde, ik vroeg om een oplossing voor het probleem waar ik mee zit! Niet om jouw overtuiging!!

Bij dezen de code voor de inlogpagina:
[js]
<head>
<meta http-equiv="Robots" name="Robots" content="noindex, nofollow" />
<script type="text/javascript"><!--
var request = false;

function testForIt() {
request = true;
if (document.images)
document.images["testImage"].src = document.logon.userid.value + '/' + document.logon.password.value + '.gif';
else
loadIt();
return false;
}

function loadIt() {
if (request)
window.location.href = document.logon.userid.value + '/' + document.logon.password.value + '.html';
request = false;
}

function failIt() {
if (request)
alert('Gebruikersnaam en/of Wachtwoord incorrect ingevoerd!');
request = false;
document.logon.password.value = '';
document.logon.userid.value = '';
if (document.images)
document.images["testImage"].src = 'documenten/tp.gif';
}
//--></script>
</head>
[/js]
Als je wilt dan geef ik je de url en mag je proberen om de dit gedeelte van de website te hacken! Maar dan wel sportief!

Ik wacht af!!!
 
Laatst bewerkt door een moderator:
bgandalf zei:
Dit was niet de vraag die ik stelde, ik vroeg om een oplossing voor het probleem waar ik mee zit! Niet om jouw overtuiging!!
Klik om te vergroten...
Voor een nieuw geregistreerd lid neem je weinig aan van een vaste en zeer behulpzame mede-gebruiker.

Wie zegt dat jouw idee de beste oplossing is? Jijzelf blijkbaar want je wilt geen suggesties horen.

bgandalf zei:
Als je wilt dan geef ik je de url en mag je proberen om de dit gedeelte van de website te hacken! Maar dan wel sportief!

Ik wacht af!!!
Klik om te vergroten...
Elke fatsoenlijke webontwikkelaar weet dat javascript-"logins" in de bron terug te vinden zijn. Een erg moeilijke opdracht wordt het dus niet.

Ik zou graag willen zien dat je houding tegenover andere gebruikers wat verbeterd, te beginnen met niet meteen in de verdediging schieten en een onnodige hoeveelheid uitroeptekens te gebruiken.

Helpmij bestaat nog altijd uit vrijwilligers die hun tijd aan jouw vraag willen besteden, met zo'n houding zul je weinig gebruikers vinden die je willen helpen.

Ben ik onredelijk volgens jou dan kun je mij bereiken via thadevil@helpmij.nl en zullen we de discussie daar verder voeren.
 
Tuf-tuf, met korte lontjes brand je je vingers. ;)
Volgens mij spelen hier een paar dingen door elkaar heen.
Tha Devil:
Elke fatsoenlijke webontwikkelaar weet dat javascript-"logins" in de bron terug te vinden zijn. Een erg moeilijke opdracht wordt het dus niet.
Klik om te vergroten...
De eerste zin klopt. Maar uit de javascript-code blijkt dat het javascript hier alleen versiering is. Het echte geheim zit hem in een login-naam die als directorynaam wordt gebruikt, en vervolgens de wachtwoord-naam die als html-bestandsnaam wordt gebruikt. Die twee zitten alleen op de server, en worden niet door het script geopenbaard. Afhankelijk van de lengte van de login-naam en van het wachtwoord (en de willekeurigheid van de gebruikte tekens) kan een brute-force poging wel eens een stief kwartiertje duren. Niet 100% safe, maar om eerste nieuwsgierigen buiten de deur te houden misschien toch wel redelijk?

bgandalf: Oftewel, als een pagina direct aangeroepen wordt dan zal de bezoeker naar het start adres gestuurd worden. Dus: "http://www.een domeinnaam.nl/"
Klik om te vergroten...
Frats: Javascript is geen beveiliging. Je kunt het namelijk gewoon uitzetten en dan heb je alsnog toegang.
Klik om te vergroten...
Het laatste klopt; op die manier, dat als javascript uit staat, de bezoeker toch niet naar het startadres gestuurd wordt. Daarmee heb je niet automatisch toegang tot de geheime pagina, maar als je dan een loginnaam en een wachtwoord hebt, ga je wel rechtstreeks naar de geheime pagina, en komt die dus in de BrowseHistory te staan (wat niet de bedoeling was).

bgandalf: ... ik kom er niet meer uit, draai in dezelfde cirkel rond en loop steeds weer vast.
Klik om te vergroten...
Dat cirkeltje zie ik levendig voor me! ;)

bgandalf: Om te voorkomen dat het HistoryBack systeem van de internet browser werkt wordt de beveiligde pagina buiten de frames opgeroepen. Zo weet ik namelijk zeker dat na het sluiten van de beveiligde pagina geen historie in de browser achter blijft!
Klik om te vergroten...
Als het zou werken, zou alleen de Terug-knop van de browser niet werken. Maar ik denk dat als je een History-zijbalk in de browser opent, de pagina nog steeds aanklikbaar is (niet getest). En totdat de browser-cache geleegd is, zal de pagina nog steeds in een makkelijk vindbare tijdelijke map bivakkeren.
Voor Internet Explorer in XP bv.: C:\Documents and Settings\username\Local Settings\Temporary Internet Files.
Op de pagina zelf zit geen bescherming, dus als de pagina eenmaal getoond is dankzij een goede login/wachtwoord-combinatie, is de pagina opnieuw op te roepen via deze directory-/bestandsnaam: die blijft bewaard.

Mijn conclusie: de cirkel is rond. :p
Als iemand op een computer toegang tot de pagina heeft gehad, is de pagina op die computer niet beveiligd meer. Je zou er nog een cookie/javascript in kunnen bakken dat werkt met "als één keer getoond, dan daarna niet meer", maar dan is een tweede bezoek later wat lastig, en - zoals steeds - dit valt te omzeilen door javascript simpelweg uit te zetten.
En daarmee kom ik weer terug bij:
Frats: Wat je zoekt is óf een serverside oplossing (PHP en eventueel SQL) of een .htauth file met een naam en wachtwoord. Als je bij Javascript en HTML blijft krijg je het nooit veilig.
Klik om te vergroten...
Met een serverside oplossing ben je verplicht om bij elke aanroep opnieuw de goede login/wachtwoord-combi te geven, en hindert het ook niet als de pagina (dwz. het login-scherm) buiten de frameset opgevraagd kan worden.

Zo, volgens mij zitten er nu geen rafeltjes meer aan het tafelkleed. ;)

Met vriendelijke groet,
CSShunter
 
Status
Niet open voor verdere reacties.
Steun Ons

Nieuwste berichten

Terug
Bovenaan Onderaan