Gå til innhold

Kryptering av url

xtin

Av xtin
i Programmering og webutvikling

Anbefalte innlegg

xtin

xtin

Skrevet
Skrevet

Hei

Jeg prøver å lage en side der brukere skal logge seg på.

Dette får jeg til, men når de er ferdig pålogget skal de bli sendt automatisk videre til sidene som de skal ha tilgang til:

 

Koden jeg har i dag er:

<body>

<form action="" method="post">

<input type="text" name="bruker" value="brukernavn" size="20" /> <br>

<input type="password" name="passord" value=""> <br>

<input type="submit" name="submit" value=" Logg på " />

</form>

 

 

<?php

include "connect.php";

 

if (isset($_POST[submit])) {

$bruker = mysql_real_escape_string($_POST['bruker']);

$passord = mysql_real_escape_string($_POST['passord']);

$result = mysql_query("SELECT * FROM paalogging WHERE bruker='$bruker' AND passord='$passord'");

 

if(mysql_num_rows($result)==0){

echo "Feil i brukernavn eller passord. Vennligst prøv igjen";

exit();

}

else{

echo "Innloggingen er fullført. Trykk på neste for å komme videre";

?>

<br>

<a href="neste.php?sikkerhet=ok">NESTE</a>

<?php

}

}

 

?>

 

Noen som kan hjelpe meg??

 

Ellers lurer jeg og på den uthevede linjen, er det mulig å sende ?sikkerhet=ok på en kryptert måte?

 

siden det blir sendt til er:

<form>

<input type="hidden" name="sikkerhet">

</form>

<?php

$sikkerhet=$_POST['sikkerhet'];

if ($sikkerhet==ok){

?>

<html>

<head>

</head>

<body>

neste

</body>

</html>

<?php

}

else{

?>

Du må være pålogget for å se denne siden.

<a href=paalogging.php>Logg deg på her</a>

<?php

}

?>

 

der det som står over og under html skal legges på flere sider, men vil helst ikke at ?sikkerhet=ok skal stå i url

 

Takk for all hjelp!

 

Xtin

Lenke til kommentar

Videoannonse

Videoannonse
Annonse
grimjoey

grimjoey

Skrevet
Skrevet

sessions bruker cookies, session_id i hidden form ved post eller i url ved get.

 

skal du ha noe relativt sikkert må du enten bruke challenge-response metodikk (implementert som http auth digest tror jeg) eller ssl.

 

du kan implementere din egen challenge-response men det krever en java applet eller javascript. klienten(browseren) må være i stand til å lage en md5sum eller annen hash.t

Lenke til kommentar
Kagee

Kagee

Skrevet
Skrevet

Jeg tør da virkelig påstå at sessions er trygt nok i dette tilfellet? Det er vel ikke DNB det skal logges inn i ?

 

Session lagres jo som cookies, men de går jo ut på dato når nettleseren lukkes? Motparten på server går jo også ut på dato etterkvart.

 

SSL har vel ingenting med å ta vare på logininformasjonen, den har jo ansvaret for å kryptere trafikken, ikke logge deg inn?

Lenke til kommentar
grimjoey

grimjoey

Skrevet
Skrevet (endret)

ssl krypterer hele tilkoblingen inkludert login headers og alt. client og server blir først enig om en felles nøkkel via diffie-helmann metoden (umulig for en sniffer å få tak i nøkkelen). som blir senere brukt med en stream cipher algorithme. (hvis jeg husker riktig - står en del om dette i wikipedia)

 

man kan selv sette cookies som går ut når nettleseren lukkes.

 

jeg responderte til at mhbakke anbefalte session fordi cookies var enkle å endre med javascript. jeg mener det ikke spiller stor rolle. session er mer automatisert. det er fordelen.

 

om det er sikkert nok er det utvikler som avgjør.

Endret av grimjoey
Lenke til kommentar
Bakke

Bakke

Skrevet
Skrevet

Det er svært lett å manipulere cookies med javscript. Det er bare å skrive javascript:alert(document.cookie) i url'en, så får du se cookien. Deretter kan du endre cookien med void(), f.eks javascript:void(document.cookie="admin=yes").

Lenke til kommentar
grimjoey

grimjoey

Skrevet
Skrevet

det samme gjelder da session med mindre session.use_cookies = 0, session.cookie_secure = 1 (kun ssl) eller session.cookie_httponly = 1 (cookie blokkert for javascript)

 

disse settingsene er forøverig tilgjengelig for alle cookies.

 

session er vel bare en mekanisme for å legge en cookie (som oftest/kan være post/get) på klient med sid som verdi.

Lenke til kommentar
grimjoey

grimjoey

Skrevet
Skrevet (endret)

login.php

<body>
<form action="" method="post">
<input type="text" name="bruker" value="brukernavn" size="20" /> <br>
<input type="password" name="passord" value=""> <br>
<input type="submit" name="submit" value=" Logg på " />
</form>


<?php
session_start();
include "connect.php";

if (isset($_POST[submit]))
{
 $bruker = mysql_real_escape_string($_POST['bruker']);
 $passord = mysql_real_escape_string($_POST['passord']);
 $result = mysql_query("SELECT * FROM paalogging WHERE bruker='$bruker' AND passord='$passord'");

 if(mysql_num_rows($result)==0)
 {
   echo "Feil i brukernavn eller passord. Vennligst prøv igjen";
   exit();
 } else {
   $_SESSION['isAuth'] = $_SERVER['REMOTE_ADDR'];
   echo "Innloggingen er fullført. Trykk på neste for å komme videre\n
   <br>\n
   <a href=\"neste.php\">NESTE</a>\n";
 }
}

?>

 

neste.php

<?php
session_start();
if($_SESSION['isAuth'] == $_SERVER['REMOTE_ADDR'])
{
echo <<< EOF

hele dokumentet her

EOF;
}
?>

Endret av grimjoey
Lenke til kommentar
Ernie

Ernie

Skrevet
Skrevet
jeg responderte til at mhbakke anbefalte session fordi cookies var enkle å endre med javascript. jeg mener det ikke spiller stor rolle. session er mer automatisert. det er fordelen.

 

om det er sikkert nok er det utvikler som avgjør.

8389806[/snapback]

Spiller ikke så stor rolle? Det spiller en veldig stor rolle skal jeg si deg. Innlogging v.hj.a. cookie er komplett idioti (av forhåpentligvis åpenbare grunner), mens innlogging v.hj.a. session er faktisk tilfredstillende sikkert for de fleste av oss. Selvsagt, session kan endres ved felles server og slikt, men er man virkelig så redd for det vil da aldri SSL hjelpe på det. Dessuten kan man jo lage sin egen session-handler hvis man så absolutt ikke kan tåle at man har delt session.
Lenke til kommentar
grimjoey

grimjoey

Skrevet
Skrevet (endret)

Slik jeg har forstått det legger session_start() blandt annet en md5 hash (SID) i en cookie (PHPSESSID) på klient og identifiserer klienten med denne cookien. $_SESSION['vars'] blir lagret i en tabell på server som linkes mot denne md5 hashen (SID)

 

Er dette korrekt ser jeg ikke hvordan session kan være sikrere en cookies. Du har mange påstander basert på lite fakta. Skulle ønske du kom med en grundigere forklaring. Sier ikke at du tar feil.

Endret av grimjoey
Lenke til kommentar
Ernie

Ernie

Skrevet
Skrevet
Slik jeg har forstått det legger session_start() blandt annet en md5 hash (SID) i en cookie (PHPSESSID) på klient og identifiserer klienten med denne cookien. $_SESSION['vars'] blir lagret i en tabell på server som linkes mot denne md5 hashen (SID)

 

Er dette korrekt ser jeg ikke hvordan session kan være sikrere en cookies. Du har mange påstander basert på lite fakta. Skulle ønske du kom med en grundigere forklaring. Sier ikke at du tar feil.

8390608[/snapback]

Nå er ikke du stort bedre ang. fakta selv da ... Men altså, ja session innebærer at det genereres en unik ID som sendes som cookie til klient/bruker. I utgangspunktet kobles denne mot en fil på serveren som inneholder data tilhørende den spesifikke session. Dette er ganske åpenbart mer sikkert en cookies som lagres hos klient/bruker. Hvis du mener noe annet så forklar hvorfor. Med mindre man har tilgang til eksakt den samme serveren vil en bruker aldri kunne endre på dataene. På samme måte må brukeren ha tilgang til samme IP som en annen bruker for at man skal kunne hijacke en annen session (dette forutsetter selvsagt at man lagrer og sjekker IPen mot bruker).
Lenke til kommentar
grimjoey

grimjoey

Skrevet
Skrevet

FraXinuS:

Bruker man session sendes en cookie med navn PHPSESSID med en unik streng til klient/bruker. For hver request sammenliknes denne cookien med hva som ligger lagret på serveren. Man kan få til nøyaktig det samme med cookies.

 

Alt dette sendes i klartekst og er leselig for alle datamaskinene mellom host og server (tracert server). Noen som har kunnskapen og resursene kan omdirigere pakker gjennom sin egen maskin og lese dataene.

 

Ernie:

Jeg bygger alle mine påstander på ting jeg har lest på enten php.net, wikipedia eller annen relevant kilde. Det jeg er usikker på spør jeg om.

 

Jeg mener at ettersom session er basert på en unik id og dette lagres som en cookie, kan man få til nøyaktig det samme ved bruk av cookies som session.

 

session er sikrere en å bare sette en cookie med statisk verdi. men har man en dynamisk verdi som er like vanskelig å gjette ser jeg ikke forskjellen.

 

SSL er forøverig ganske sikkert. Finnes ingen kjent måte å knekke det på effektivt.

Lenke til kommentar
Ernie

Ernie

Skrevet
Skrevet
Jeg mener at ettersom session er basert på en unik id og dette lagres som en cookie, kan man få til nøyaktig det samme ved bruk av cookies som session.

8391225[/snapback]

Nøyaktig det samme som med session? Den der må jeg nesten se i praksis. Med mindre du separerer med et eller annet tegn skal det være komplett umulig. Som sagt, session-dataene blir lagret på serveren til stor forskjell fra hva du kan med en cookie.

 

session er sikrere en å bare sette en cookie med statisk verdi. men har man en dynamisk verdi som er like vanskelig å gjette ser jeg ikke forskjellen.

8391225[/snapback]

dynamisk verdi? Hva mener du egentlig med det? Hvorfor skal det være sikrere i sammenheng med cookie?

Lenke til kommentar
FraXinuS

FraXinuS

Skrevet
Skrevet
FraXinuS:

Bruker man session sendes en cookie med navn PHPSESSID med en unik streng til klient/bruker. For hver request sammenliknes denne cookien med hva som ligger lagret på serveren. Man kan få til nøyaktig det samme med cookies.

Ja det kan man, men forskjellen er at cookie data blir lagret hos klienten og session data blir lagret på serveren. Det betyr at en variabel lagret i en cookie kan man ikke stole på for den kan endres av klienten, men en session variabel kan kun endres av serveren, derfor er den sikrere.

Lenke til kommentar
grimjoey

grimjoey

Skrevet
Skrevet (endret)

dynamisk verdi er en verdi som endrer seg hver gang den samme, eller en annen, bruker logger seg på. det kan være for eksempel setcookie('PHPSESSID',md5($_SERVER['REMOTE_ADDR'].time().srand(blabla),...).

 

SID blir lagret på klient som en cookie. (hvis ikke server bruker GET/POST som nevnt tidligere). Lokalt lagrer serveren alle session variablene med referanse til SID.

 

Det samme kan gjøres uten å bruke "sessions".

 

Man kan legge så mange variabler man vil i en fil på serveren (fputcsv(), fwrite(), ...) med referanse til en dynamisk verdi man setter som cookie hos klient. Man kan lagre til en lokal database server. Det holder med at en referanse verdi finnes hos klient på samme måte som gjøres ved bruk av sessions.

 

Det å bruke sessions er lettere. Og sikrere enn å legge alle klient variablene som cookies. Det som startet diskusjonen var at jeg sa at sessions ikke er noe sikrere en cookies fordi det i prinsipp er det samme (ellernoe). La meg si det på en annen måte.

Sessions er ikke noe sikrere en hva man kan få til ved bruk av PHP og cookies uten "session".

 

Ernie: "Med mindre du separerer med et eller annet tegn skal det være komplett umulig." - kan du forklare?

Endret av grimjoey
Lenke til kommentar
grimjoey

grimjoey

Skrevet
Skrevet (endret)

Jeg har forsøkt å sette meg litt inn i sikkerheten rundt sessions. Jeg har skrevet et dokument for å få litt oversikt over hva som kan/bør gjøres for å oppnå best mulig sikkerhet.

 

Vil gjerne ha kommentarer/forbedringer...

 

Dokumentet følger:

 

Klikk for å se/fjerne innholdet nedenfor
Something Content Management System - developement layout, later readme.txt

 

version: 0.1d - developement

original author: Jo Are By (j-ar-b online no)

last edit: 070407 (yymmdd)

 

Licensed by this documents license. The following paragraph.

 

A change means info from this document not in original state is publicly available. Anyone can use info from and/or edit this document by the following rules in this paragraph. Do not remove data. If you make changes keep a copy of the original tekst at the end of changed document. If changes are made an author identifying string must be appended to the version name like "developement -> development.addauthor". If changes are made by original author these rules do not apply.

 

Dependancies: any php enabled web server, PHP, mySQL

Utilises: HTML, (CSS, Java, Javascript, SSL, Cookies) [optional]

 

Words:

Session - Authenticating a user on connections following the first user authentication without the user having to state the username and password every time.

Hash - A string of characters(bits, whatever) with a specified length that is generated from a different string (the password) of unspecified length whereas the latter cannot be generated from the first and they are equally unique by a very high probability. Used to hide/obscure passwords.

 

Security:

This program have different security options to which usability is determined by server configuration.

If SSL is not being used, security is dependant on the client. If Java is enabled on the client a Java applet can be used to encrypt the login information by ways of hashing, key-strenghtening and challenge-response key authentication. If Cookies and Javascript are enabled on the client the Java applet can also provide a key for session authentication, only vulnerable to brute force, dictionary attack (none of these really applicable because of key-strenghtening and hash input seeding) and/or presently (by the last edit of this document) unknown hashing algorithm errors.

 

The challenge-response mechanism has one big drawback. The password hashes stored in the database are not safe for viewing. When using hashes not transmitted over an insecure connection the hash can be viewed by anyone without much security consern (only brute force/dictionary attack applicable). One unique password generates one unique hash by a very high probability. The password is hashed and compared to the stored hash. They are equal if the passwords used to generate both are equal. If you use the hash as a password it is again hashed and a different hash is compared to the one stored. The problem with challenge-response is that the hash stored in the database for each user is used to generate å unique hash every time a user tries to authenticate. the value (called nonce) that creates uniqueness is sent in plain text. So if someone, like a system admin on a shared host (with permissions to the mySQL server), is able to view the database hashes, anyone of these hashes can be used with the nonce (uniqueness value) to provide a successful authentication. All users are in effect compromised.

 

It is possible to handle user rights according to security. For instance you can force users read-only access if SSL is not used and Java, Javascript and Cookies are not enabled in their browser in which case there is no secure user authentication nor secure session management.

 

Keep in mind that if SSL is not used, all information is readable by a third party. The security mechanisms in the program only provide reasonable safe authentication for user and session.

 

If the mySQL database is on a different server and no encryption is used on the connection, security is severely compromised (especially if using challenge-response). Please keep the servers on the same host or use SSL/SSH encryption or some other secure tunneling.

 

Keep passwords complex and safe!

 

Options:

DatabaseType = [mysql(default)] - Currently only supported is mySQL.

DatabaseHost = hostname - Host to connect mySQL client.

DatabaseUser = username - Username used to connect to mySQL client on specified host.

DatabasePass = password - Password used to authenticate specified username.

DatabasePrefix = prefix - Prefix to be added to database and table names to increase security. Keep it non-obvious. (SQL injection attackers cannot guess table names so easily).

DatabaseFiles = [Yes (default), No] - Determines whether files are stored in database or filesystem.

SecurityUseChallengeResponse = [Yes (default), No] - Use challenge-response mechanism (Good when not SSL)? Otherwise use static hash compare (Good with SSL + remote mySQL server, keeps database passwords safe for viewing).

SecurityJavaEnable = [Yes (default), No] - Enable Java?

SecurityJavaScriptEnable = [Yes (default), No] - Enable JavaScript?

SecutityCookiesEnable = [Yes (default), SSL, No] - Enable Cookies in http (quite safe with Java, JavaScript and RestrictedUser), https/SSL only or not at all?

SecurityRestrictedUser = [Yes (default), No] - Restrict user to read-only access on basis of security available (write access requirements: SSL and/or [Java, JavaScript and Cookies enabled in client])? This will send user new generated password by email and force user read-only until new password is being used with a write access authentication following removal of the old password.

UseHTTPAuthBasic = [Yes, No (default)] - Use http basic authentication instead of form POST. (plain text, insecure unless SSL)

UseHTTPAuthDigest = [Yes, No (default)] - Use http digest authentication instead of form POST. (challenge - response, secure authentication, database password hashes not secure for viewing)

Forum = [Yes (default), No] - Enable forum?

Admin = [Yes (default), No] - Enable online editing (Highly recommended being much of the point of CMS)?

CSS = [Yes (default), No] - Enable CSS?

 

Tagging:

<STG insert=[option]>

 

Tagging options:

title - insert title from file or database

menu - insert dynamic menu drawn from filenames or database

content - insert dynamic content drawn from files or database

 

Java is a trademark of Sun Microsystems.

 

 

----developement-notes-remove-later----

Security problems:

Passwords are only safe to set over encryptet connection. Email new password may be unsafe.

Endret av grimjoey
Lenke til kommentar
FraXinuS

FraXinuS

Skrevet
Skrevet
Man kan legge så mange variabler man vil i en fil på serveren (fputcsv(), fwrite(), ...) med referanse til en dynamisk verdi man setter som cookie hos klient. Man kan lagre til en lokal database server. Det holder med at en referanse verdi finnes hos klient på samme måte som gjøres ved bruk av sessions.

Men det blir jo akkurat det samme, bare at du lager ditt eget session system istedet for å bruke det innebygde i php.

Lenke til kommentar

Opprett en konto eller logg inn for å kommentere

Du må være et medlem for å kunne skrive en kommentar

Opprett konto

Det er enkelt å melde seg inn for å starte en ny konto!

Start en konto

Logg inn

Har du allerede en konto? Logg inn her.

Logg inn nå
Gå til emneliste

  • Hvem er aktive   0 medlemmer

    • Ingen innloggede medlemmer aktive
×
×
  • Opprett ny...