Passwort-Abfrage über clientseitiges JavaScript nicht sicher. Weshalb?

  • Themenstarter Themenstarter Gelöschtes Mitglied 7427
  • Beginndatum Beginndatum
G

Gelöschtes Mitglied 7427

Guest
Code:
Hallo zusammen

ich möchte gerne meine Seite mit einem einfachen Dialog schützen, htaccess möchte ich aber nicht brauchen. Ich lese auf diversen Seiten im Netz immer wieder, dass eine Passwort-Abfrage über ein clientseitiges Javascript nicht sicher sei. Habe deshalb mal ein Script im Internet runtergeladen, aber dieses ist offenbar anders aufgebaut, als diese, die ich gefunden habe:

Code: 
<script language='JavaScript'>
		var time= '09.03.05 20:06:41' ;
		var i=0;
		var UserID='';
		passwort = window.prompt('Passwort:','');	
		if((passwort != null)&&(passwort != "")){
			passwort = passwort.toLowerCase();
			while (passwort.length < time.length){passwort=passwort+passwort;}
			for (i=0;i<time.length;i++){UserID=UserID+(100+passwort.charCodeAt(i)+time.charCodeAt(i))}
			link = window.location.href.split('?');
			window.location.href =link[0]  + '?UserID=' + UserID;
		}//if
		else window.location.href='http://www.your-homepage.com'
		</script>

Als ich bei google nach einem Seiten-Schutz mit JavaScript gesucht habe, fand ich auf diversen Seiten das:

Code: 
<SCRIPT LANGUAGE="JavaScript" TYPE="text/javascript">
<!--
var kennwort = "geheim"

function go(knw)
{
  if(knw == kennwort)
    location.href = "dokument.htm"
  else
    alert("Geben Sie bitte das richtige Kennwort ein.")
}

// Nur fuer Alternative:
function wechsel_mit_kennwort()
{
  go(prompt("Kennwort:", ""))
}
// -->
</SCRIPT>

Diese beiden Codes sehen etwas anders aus und im oberen kann ich das Passwort nicht erkennen. Ist dieses sicher? Entschuldigt, dass ich so eine doofe Frage stelle, aber das hat mich schon ein wenig verwirrt.

Daniel 8)
 
Hallo,
also das Obere ist kein wirklicher Passwortschutz.

Und zwar wird aus dem eingebenen Passwort ein Code errechnet. Der User wird dann an: seite_12345.html weitergesendet.
Sofern man nicht den richtigen Code hat, wird man an eine andere Seite weitergeleitet.

Das wäre aber das Gleiche Prinzip, als wenn du deinen Freunden den Link:
http://seite.de/ganz_geheime_seite_nicht_weiter_sagen.html

sendest, und nicht den Passwortcode. Sofern jmd. die URL der geheimen Seite herrausfindet, dann kann er auch ohne PW diese Aufrufen.

Bei der zweiten Lösung kann man das PW einfach ablesen, oder man geht gleich auch dokument.htm

Die einzig sichere Lösung ist recht kompliziert.

Und zwar gab/gibt es bei PGP und auch anderen Tools eine Möglichkeit, Texte zu verschlüsseln.

Diese Texte werden als HTML Datei abgespeichert. Wenn man diese Datei aufruft, ist dort ein Formular. Wenn man dann wieder das Passwort eingibt, und auf Entschlüsseln klickt, bekommt man den Klartext.

Dies könnte man so umändern, dass beim Aufruf der Webseite ein JS-Popup Eingabefenster erscheint. Dort gibt man dann den Key/Passwort ein.

Dann wird dieser Key benutzt um den Text zu entschlüsseln. Dieser Text enthält die Informationen der Seite ink. Formatierung.
Der entschlüsselte Text wird dann zurück gegeben und sofern der Key richtig war, auch richtig dargestellt.

Wie du siehst, ist das gar nicht so leicht, und Änderungen am Quellcode sind auch nur kompliziert möglich.

P.S. Programme die eine Source verschlüsselt abspeichern, aber so dass der Browser _ohne_ Key Eingabe die Seite darstellen können, sind _nicht_ sicher.
 
Und welche Seite wäre das im oberen Fall? Ich möchte das gerne mal auf meinem Server testen und einen Skriptkiddie, ein Kolleg von mir, draufloslassen und dann eine Seite machen, auf der seine "Leistung" bekannt gegeben wird.

Weil wenn ja ein Code erstellt wird, muss die Seite dazu ja auch vorhanden sein.

Daniel 8)
 
relativ sichere und einfachere variante ist, wenn sich aus dem passwort die weiterleitungs url ergibt. so kommt man mit richtigen pw auf die seite und bei falschen pw gibts ein 404 (seite nicht gefunden). am besten packt man noch ne hashfunktion dazwischen.

also zB:
passwort = "LetMeIn1337";
md5("LetMeIn1337") = 51711599afd6251394b1ef644661eab0
-> weiterleitung auf die seite 51711599afd6251394b1ef644661eab0.html

directory listing sollte natürlich deaktiviert sein.
 
Original von dfi
Und welche Seite wäre das im oberen Fall?
Zum Vergrößern anklicken....

Oder muss ich jetzt einfach eine Datei mit dem Namen "abc123.htm" erstellen, und schon ist das Passwort "abc123"? Und in meinem geposteten Script ist das Passwort ja eben nicht enthalten, wird dann einfach nach der Seite gesucht, und wenn sie gefunden wurde, darauf weitergeleitet?

Daniel 8)
 
Ich finde die Lösung von ivegotmail ist gut, wenn dein Kollege an nem anderen PC sitzt und das ganze über nen Webserver läuft, geht das.
Aber n Apache (oder ähnliches :D) ist halt nicht für jede Firma Standart. (vor allem nicht wenn se nichts mit Webdesign zu tun haben ;)) Weiß nicht, wie du das machen wolltest.
Wenn du aber (ich geh mal (weils in "der Firma" ist) von Win aus) den Explorer öffnest und deinem Kollegen von den beiden Datein (index.html und 51711599afd6251394b1ef644661eab0.html) index.html öffnest, ist das keine wirkliche Herausforderung mehr. (Ich denke nicht, das du sowas tust, ich sachs halt nur mal ;))

Außerdem würde eine Brute-Force Attacke mit beliebigen Seitetiteln die lösung innerhalb des nächsten Jahrtausends ermitteln :P.

Wenns wirklich lokal ist, ist nur Elderans Methode sicher. Also, die ganze Seite verschlüsseln (so, wie sichere Datenübertragung übers Web halt funktioniert, nur ohne die automatische Umwandlung am Client).

Für "normal sterbliche" mit Webserver würd ich aber ivegotmails Methode vorschlagen, oder wenigstens das Passwort nur als Hash speichern, auch wenn der Quellcode dann ablesbar ist. (is dann aber nur gegen Eintastenmäuse sicher :D)
 
Original von ivegotmail
relativ sichere und einfachere variante ist, wenn sich aus dem passwort die weiterleitungs url ergibt. so kommt man mit richtigen pw auf die seite und bei falschen pw gibts ein 404 (seite nicht gefunden). am besten packt man noch ne hashfunktion dazwischen.

also zB:
passwort = "LetMeIn1337";
md5("LetMeIn1337") = 51711599afd6251394b1ef644661eab0
-> weiterleitung auf die seite 51711599afd6251394b1ef644661eab0.html

directory listing sollte natürlich deaktiviert sein.
Zum Vergrößern anklicken....

Mich würde dabei interessieren ob ich die Site trotzdem via Intellitamper/Teleport Pro oder ähnlicher Software finden kann. Da sich die Site ja in keinem htaccess-Bereich befindet, würde das vermutlich klappen.

root
 
Original von SUID:root
Mich würde dabei interessieren ob ich die Site trotzdem via Intellitamper/Teleport Pro oder ähnlicher Software finden kann. Da sich die Site ja in keinem htaccess-Bereich befindet, würde das vermutlich klappen.
Zum Vergrößern anklicken....
auf der homepage von Intellitamper steht folgendes:
IntelliTamper is also able to scan a website for unlisted files and folders with a dictionnary based scan.
...
The public scan is based on precise and recursive HTML analysis, then a dictionnary of common files and folders names is used to try to discover hidden parts of the server.
Zum Vergrößern anklicken....
also $hash.html gehört mit sicherheit nicht zu gebräuchlichen dateinamen. von daher solte das tool die seite nicht finden.
 
Hallo,
Ich würd das ganze mit PHP machen, das ist wirklich nicht schwer.
Zum Vergrößern anklicken....
Es gibt Webserver die leider _noch_ kein PHP unterstützen.

Mich würde dabei interessieren ob ich die Site trotzdem via Intellitamper/Teleport Pro oder ähnlicher Software finden kann.
Zum Vergrößern anklicken....
Diese Software ist so wie ein Browser, bloß dass die Antwort vom Server als Datei gespeichert wird.

Diese Software/Browser kann aber nichts anderes als dein Firefox, Opera, IE... Sprich der Browser fragt den Server: Sende mir mal die Datei abc.html zu.
Server: Ok, hier ist sie
Browser: Danke. [Speichern|Anzeigen?]

Sofern jetzt in dem Ordner eine index Datei vorhanden ist, oder directory listin auf OFF steht, ist der Browser "blind". Sprich dieser kann nur den Links der Dateien folgen.

Und der Dateiname besteht aus 128 Bit, also gibt es 2^128 = 10^38 Möglichkeiten. Dass das Programm alle austesten.... unwahrscheinlich.

Man hat nur ein sehr großes Problem, wenn jmd. an deinen PC geht, und in deinem Verlauf den Pfad zum "geheimen Dokument" findet. Denn dann kann er ohne Passwort dieses Dokument aufrufen.
 
hm

Hi,

Was hast du gegen die .htpasswd ???

1.
Die legst du in das Verzeichnis was eine Ebene höher liegt und gibst das der .htaccess bekannt.
ich meine da kommt man nicht so ohne weiteres ran wenn der Webserver einigermaßen durchschnittlich aufgebaut ist und die oberen Verzeichnisse nicht im Web veröffentlicht :- ).
Passwörter können durch diverse Tools natürlich mit so einer 0-9 A-Z etc... Variante durchprobiert werden. Daher mußt du hier auch ein wenig kreativ mit der Paßwortvergabe sein. Sätze haben viele Zeichen und erschweren dieses wahnsinnig. Da würde es schon mal nen paar Tage brauchen wenn der Username bekannt wäre.
Die HP zu der es am Ende gehen sollt am besten in einem komplett anderen Unterverzeichnis hosten als wo die .htaccess liegt.

Zudem lohnt es immer eine .swf Flashdatei davor zu bauen die nicht sofort den Link anzeigt wo es zur .htaccess geht. Ist nochmal nen kleiner Schutz zusätzlich den Versuch alleine schon mal etwas zu erschweren. (wenn auch lächerlich).

SYD
 
Hallo,
also die .htaccess hat _nichts_ mit dem Schutz zu tun. Die kann jeder einsehen und es wäre kaum ein Sicherheitsrisiko.
Dort steht dann nur drin, wo es zur .htpasswd geht, gut dadurch könnte man den Dateipfad herrausfinden, aber das geht auch anders.
Und noch dass der Ordner per PW geschützt ist.

Was geheim gehalten werden muss ist die .htpasswd.
Dort sind _verschlüsselt_ die Passwörter gespeichert. Und wenn man ein gutes Passwort hat, dann kann man dieses mit uns bekannten Angriffen und Technologie nicht innerhalb eines Menschenlebens knacken.

Allerdings kann man auf beide Dateien _nicht_ per Browser zugreifen, sofern man dieses in der Config nicht deaktiviert hat.

Und wenn jmd. FTP Zugriff hat, dann könnte er die geheimen Dateien auch ohne den Umweg über .htpasswd => PW entschlüsseln an die Daten kommen.

Aber wie gesagt, es gibt viele Anbieter, vorallem kostenlose, die weder Serverseitigesprachen nocht .htaccess oder ähnliches unterstützen.
 
Original von Elderan
Was geheim gehalten werden muss ist die .htpasswd.
Dort sind _verschlüsselt_ die Passwörter gespeichert.
Zum Vergrößern anklicken....
Der Vollständigkeit halber kann man noch dazu sagen, dass sie unter Win NICHT verschlüsselt gespeichert werden sollen, sondern in plain text. Die mir bekannten Webserver verschlüsseln die ab zu gleichenden Passwörter vor dem Abgleichen nicht.
(Was für ein Satzmonster :D Hoffe, was ich aussagen wollte ist an gekommen)
 
Hi!

Ich empfehle dir auf jeden Fall .htaccess (oder die Serverkonfiguration) zu verwenden.
.htaccess finde ich die beste Möglichkeit für Passwortabfragen und geschützte Bereiche! :D

Ich hab ein kleines Tutorial geschrieben, kannst es dir ja mal durchlesen:

-----------------------------------------------------------
.htaccess - Einführung


Was ist eine .htaccess-Datei?

Die .htaccess-Datei ist eine Konfigurationsdatei, mit der man die Standardkonfiguration
des Webservers (Apache) für bestimmte Verzeichnisse ändern kann. Man speichert eine
Datei names .htaccess in dem Verzeichnis, in dem man die Konfiguartionsänderungen
machen möchte. Sie gilt für dieses Verzeichnis und alle Unterhalbliegenden.

Den Namen der .htaccess-Datei kann man mit folgendem Befehl in der Server-Konfigurationsdatei ändern:

/etc/httpd.conf
....................................
AccessFileName .conf
....................................


Welche Befehle gibt es?

Welche Befehle in einer .htaccess-Datei akzeptiert werden, wird durch 'AllowOverride' gesteuert.
Ob es überhaupt möglich ist, diese Directive in einer .htaccess-Datei zu verwenden, steht in der Dokumentation.
Um herauszufinden welches 'AllowOverride' man einfügen muss und ob es möglich ist, diese Directive zu verwenden,
genügt ein Blick auf die Homepage von Apache.

Hier ein Beispiel mit 'Require':
In der Dokumentation von Apache (unter Directives => Require) steht folgendes:

Apache-Manual
....................................
[...]
Context: directory, .htaccess
Override: AuthConfig
[...]
....................................

Das heisst, dass man diese Directive in einer .htaccess-Datei verwenden darf und
dass man vorher Require mit 'AllowOverride' in der Serverkonfiguration erlauben muss,
damit 'Require' funktioniert:

/etc/httpd.conf
....................................
AllowOverride AuthConfig
....................................


Was ist, wenn ich in tieferen Verzeichnissen Optionen wieder verbieten will?

Wieder ein Beispiel:

/usr/var/www/htdocs/board/.htaccess
....................................
Options +ExecCGI
....................................

/usr/var/www/htdocs/board/admin/.htaccess
....................................
Options Includes
....................................

Damit ist CGI im Verzeichnis 'board' erlaubt, jedoch nich im Verzeichnis 'admin'.
Eigentlich ganz einfach, oder?


Wie kann ich CGI in bestimmten Verzeichnissen erlauben?

Durch genau diese Frage, bin ich auf die Idee gekommen, ein kleines Tutorial über .htaccess zu schreiben.
Ich habe Board-Software, welche in Perl geschrieben ist demnach CGI verwendet, jedoch in allen möglichen Verzeichnissen.
Da es nicht mein eigener Server ist, auf dem ich das Board hoste, habe ich nur die .htaccess-Datei zur Verfügung.

/home/martin/public_html/bbv2/.htaccess
....................................
Options +ExecCGI
AddHandler cgi-script cgi pl
....................................

Erledigt!
Man muss 'Options' durch 'AllowOverride' erlauben (in der Serverkonfiguration), um es benutzen zu können.
In der 1. Zeile wird CGI in diesem Ordner (/home/martin/public_html/bbv2) erlaubt.
Mit der 2. Zeile werden alle Dateien, mit Endung .cgi oder .pl als CGI-Datei behandelt und ausgeführt.
Das war's!


Wie kann ich bestimmte Verzeichnisse mit einem Passwort absichern?

Das ist wohl der häufigste Grund, warum .htaccess benutzt wird - Passwortschutz!
Ok von Anfang an:
Ein Blick in die Dokumentation verrät uns, dass man 'AuthConfig' mit 'AllowOverride' erlauben muss.

/etc/httpd.conf
....................................
AllowOverride AuthConfig
....................................

Danach muss man eine Passwortdatei erstellen und evtl. eine Gruppendatei.
Die Passwortdatei wird mit 'htpasswd' erstellt, ein Tool, das bei Apache mitgeliefert wird.

SHELL
....................................
htpasswd -c /usr/local/apache/passwd/passwords
....................................

Das Flag -c wird nur beim Erstellen einer neuen Datei benutzt. Es darf nur beim Ersten User
benutzt werden, sonst wird die Datei wieder überschrieben.
Als 2. Argument folgt die Passwortdatei.
Danach sollte man die richtigen Rechte setzen, um einer Kompromittierung vorzubeugen.

SHELL
....................................
chmod root:apache /usr/local/apache/passwd/passwords
chmod 640 /usr/local/apache/passwd/passwords
....................................

Nachdem die Passwortdatei erzeugt ist, kann man sich endlich der Konfiguration zuwenden.

.htaccess
....................................
AuthType Basic
AuthName "Passwortabfrage!"
AuthUserFile /usr/local/apache/passwd/passwords
require valid-user
....................................

Zur Erklärung:
'AuthType' gibt den Typ der Authentifizierung an (Basic == Passwort eingeben). Es gibt noch andere Verfahren ,wie z.B.
die Authentifizierung per Datenbank, IP usw.
'AuthName' ist die überschrift der Dialogbox als String.
'AuthUserFile' ist die Passwortdatei. (Immer den absoluten Pfad angeben)
'require valid-user' bedeutet, dass eine Passwortdatei benutzt werden soll.

Es gibt noch viele weitere Befehle wie

.htaccess
....................................
require user tcr
....................................

Sodass nur Benutzer 'tcr' Zugang erhält. ;)

Man kann auch Gruppen verwenden:

.htaccess
....................................
AuthGroupFile /usr/local/apache/passwd/groups
require group admins
....................................

Wobei die Gruppendatei so aussieht und sich auf die Passwortdatei bezieht:

/usr/local/apache/passwd/groups
....................................
admins: bow00 Chris tcr
....................................


Sonstige Überlegungen?

Eigentlich sollte man eine .htaccess-Datei nur benutzen, wenn man keinen Zugriff auf
die Server-Koniguration hat. Die Benutzung der Serverkonfigurationsdatei hat hauptsächlich
einen Vorteil:
Die Datei wird nur geladen, wenn der Server (neu)gestartet wird.

Folgendes Verzeichnis:

....................................
/usr/var/www/htdocs/board/hacks
....................................

Es wird in also folgenden Verzeichnissen nach einer .htaccess-Datei gesucht:

....................................
/usr/var/www/htdocs/board/hacks
/usr/var/www/htdocs/board
/usr/var/www/htdocs
....................................

Es wird tatsächlich in 3 Verzeichnissen nach einer .htaccess-Datei gesucht. Ob sie gefunden wird
oder nicht ist egal, gesucht wird auf jeden Fall.
Damit noch nicht genug:
Es wird bei jedem Neuen Laden einer Seite danach gesucht!
Bei einer größeren Site kann das zu einigen Performance-Verlusten führen.

Eines soll noch demonstriert werden:

/usr/var/www/htdocs/board/.htaccess
....................................
AddHandler cgi-script cgi pl
....................................

/etc/httpd.conf/.htaccess
....................................
<Directory /usr/var/www/htdocs/board>
AddHandler cgi-script cgi pl
</Directory>
....................................

Beide Einträge sind völlig identisch, sie machen genau das Gleiche!


Warum wird aber dann die .htaccess-Datei so oft benutzt?

Ganz einfach:
Viele Hoster hosten mehrere User auf einer einzigen Maschine, und damit jeder User seine eigenen
Einstellungen (Anmeldung, Index-Seiten) konfigurieren kann, wird die .htaccess-Datei erlaubt.

Das war's, hoffe ihr habt was gelernt, denn dann gibt es ein paar Kiddies weniger! ;)

written by tcr
-----------------------------------------------------------

mfg
tcr
 
hui

SUPER

So schön ausführlich !
Nun kann es aber auch ein 7 Jähriger der etwas lesen kann.
Wenn das alle so machen würden...... 8)


SYD
 
Ja!

Hab noch eins geschrieben, das trifft das Thema vielleicht etwas besser:

-------------------------------------------------------------------------------------
Heute mal ein Tutorial über Javascript-Passwortabfragen!

Grundsätzlich lässt sich sagen, dass Passwortabfragen mit Javascript
ein großes Sicherheitsrisiko darstellen. Außerdem kann man Javascript
aus Sicherheitsgründen auch deaktivieren, sodass man im besten Fall
nur eine Fehlermeldung bekommt.
Man kann Passwortabfragen viel effizienter gestalten, z.B. mit .htaccess
(siehe mein anderes Tutorial), oder mit PHP und einer Datenbank. Da es hier aber um Javascript geht, werde ich jetzt nicht weiter auf andere Möglichkeiten eigehen.

Grob gesehen kann man alle JS-Passwortabfragen in 4 Bereiche einteilen:

1) Passwortabfragen, bei denen das Passwort im Quelltext steht,
2) Passwortabfragen, die ein js-Datei zum verifizieren benutzen,
3) Passwortabfragen, bei denen Passwörter ausgerechnet werden und
4) Passwortabfragen, bei denen das Passwort die HTML-Datei ist.

1)
Ich glaub, wer solche Passwortabfragen programmiert, der hat die letzten Jahre etwas geschlafen. Das Passwort kann man einfach im Quelltext lesen und das war's. Einfacher geht's nun wirklich nicht mehr. Allerdings kann folgendes möglich sein:
Solange das Script läuft ist alles Andere deaktiv. Meist wird ein nachheriges Auslesen dadurch verhindert, das ein Alert
erscheint wie "Passwort falsch" und das Script von neuem gestartet wird. Beim Internet Explorer gibt es z.B. das Zonen-Modell und wenn man einfach in Diesem die Sicherheitsstufe auf hoch stellt, wird Javascript verboten und schon kann man sich den Quellcode ansehen.
Hier ein einfaches Beispiel:
Code: 
<SCRIPT>
function dialog()
{
	var Eingabe;
	while (Eingabe!="Passwort" || Eingabe!="Password")
	{	
		Eingabe=prompt ("Passwortabfrage/ Bitte tragen Sie das Passwort ein.");
		if (Eingabe=="Passwort" || Eingabe=="Password")
		{
			break;
		}
		else
		{
			alert("leider falsch!");
		}		
	}
	window.location ="admin.html";
}
</SCRIPT>
In diesem Beispiel heißt das Passwort also entweder 'Passwort' oder 'Paswword'. Falls Dieses richtig eingegeben wurde, wird man automatisch nach 'admin.html' weitergeleitet.

2)
Passwortabfragen, die ein js-Datei zum verifizieren benutzen, sind eigentlihc genau das Gleiche wie Punkt 1. Der einzige Unterschied ist, dass der Quellcode extern in eine andere Datei ausgelagert wird. Im Quellcode könnte z.B. folgendes stehen:
Code: 
<SCRIPT>
	src="login.js">
</SCRIPT>
Wenn man sich dann die Datei anschaut hat man also auch den reinen Quellcode vor sich, also wie im Beispiel zu Punkt 1.
Mehr brauch ich dazu also nicht zu sagen, da es ja ziemlich das Gleiche ist.

3)
Punkt 3, was soll man dazu sagen. Wird eigentlich auch nur noch in Crackme's verwendet. Das Passwort wird aus verschiedenen Funktionen ausgerechnet. Es stehen dabei alle Möglichkeiten zur Verfügung. Am Besten wieder mal ein Beispiel:
Code: 
<SCRIPT>
	var string1="abcdefghijklmnopqrstuvwxyz~_.-:#/AB"
	+"CDEFGHIJKLMNOPQRSTUVWXYZ1234567890@!%^&*";

	string2=string1.substring(52,53)+string1.substring(4,5)+string1.substring(18,19)
	+string1.substring(52,53)+"";
	string3=string1.substring(20,21)+string1.substring(18,19)+string1.substring(4,5)
	+string1.substring(28,29)+string1.substring(7,8)+string1.substring(19,20)
	+string1.substring(12,13)+string1.substring(11,12)+"";

	var name = prompt("Bitte geben Sie Ihren Namen ein:", "Javascript-Abfrage")
	if (name ==string2) 
	{
		(confirm("Passwort richtig.")) 
	}
	else
	{
		alert("Die Eingabe: " + name + " ist ungültig!");
		history.back();
	}
</SCRIPT>
'string1' ist ein Zeichenarray, 'string2' ist das Passwort (kann man ja an der if-Anweisung erkennen), 'string3' ist nur zur Verwirrung der Newbies da. Es werden also einzelne Zeichen aus 'string1' herausgesucht, anstatt das Passwort einfach 'so' in den Quellcode zu schreiben. Auch nicht wirklich sicher. Wie man das Ausnutzen kann zeige ich jetzt:
Zuerst speichert man die Datei als html-Datei lokal ab. Dann sieht man sich den Quellcode an und fügt in der else-Anweisung folgenden Befehl ein:
Code: 
alert(string2);
Wenn man nun die lokale Seite aufruft, das falsche Passwort eingibt wird das Passwort ausgegeben. Mehr brauche ich glaube ich auch nicht dazu zu sagen.

4)
Jetzt kommt meine Lieblingmethode, obwohl sie auch nicht sehr sicher ist, wird es doch eher unwahrscheinlich, dass man Diese so einfach wie oben crackt. Mit einem Satz kann man diese Methode beschreiben: Das Passwort ist der Name, der Seite, die aufgerufen werden soll.
Ein Beispielcode:
Code: 
<SCRIPT>
function checkPassword()
{
	pw=prompt("Bitte geben Sie das Passwort ein:","");
  	if( pw != ""  &&  pw != null)
    	window.location=pw + ".html";
}
</SCRIPT>
Wie man am Code erkennen kann, wird man auf folgende Seite weitergeleitet: <passwort>.html!
Wenn einem der Name der 'geschützten' Seite allerdings bekannt ist, wird diese Methode gar Nichts bringen. Es gibt Möglichkeiten, wie Dateinamen erraten (admin.html, login.html, ...) oder aber Directory-Listing. Letzteres ist zwar eher wenig gesehn, aber jedoch nicht ausgeschlossen.

So das war mein Howto über Javascript-Abfragen. Fragen könnt ihr wie immer gleich im Board posten oder ihr könnt euch direkt an mich wenden (
email.png
).

Viel Spaß beim Ausprobieren!
tcr
-------------------------------------------------------------------------------------

mfg
tcr
 
Um antworten zu können musst du eingeloggt sein.
Zurück
Oben