05. april 2002 - 15:15Der er
7 kommentarer og 3 løsninger
Sikkerhedshul eller?
Hejsa, jeg har lavet mig en krypterings funktion, der krypterer brugernavn og password i alm. Javascript og sender det til ASP-siden, hvor det dekrypteres i ASP, og valideres i forhold til en tabel databasen. I mit sql kald til DB SELECT'er jeg * altså alle records op, da jeg ved det kan være farligt at bruge WHERE betingelser, så man kan indtaste ting som : 'or username like '% i form felterne. Krypterings funktion i Javascript kan jo ses med view-source, i teorien eller kan det jeg har lavet et lille script, der gør man ikke kan højre klikke med musen og det er i frames. Så man heller ikke gå op i vis og vælge viewsource. Har jeg umiddeltbart nogen huller?
I dette særtema ser vi på, hvordan cloud og AI bliver fundamentet for virksomhedernes digitale forretning, og hvordan de nye muligheder for automatisering og forretningsværdi kan udnyttes uden at miste overblik, sikkerhed og menneskelig kontrol.
Hvis din krypteringsfunktion ligger i JavaScript kan den læses - og du kan ikke skjule det med no-non-right-click. Der er andre måder at afkode det på.
WHERE betingelsen er ikke farlig i sig selv. Men hvis du ikke validere dine inputs kan den være farlig som du selv skriver. Men hvis du checker at der virkelig står et brugernavn og et password så er den ikke mere farlig en noget andet. Husk dog at checket skal ligge i asp koden og ikke i klienten.
Men hvad er det du vil beskytte? At nogen tapper kommunikationen mellem clienten og serveren? Hvis det er det du vil, så er din ide måske ok - forudsat at din krypteringsrutine kan måle sig med f.eks. SSL. Og det er ikke noget at komme og sige "Jep - jeg bruger 782323bits kryptering".. Det handler om hvordan du danner dine nøgler. Hvis din nøgle står i din kode er det ligegyldigt om du bruger 1 eller en fantasillion bits kryptering
I mit klient-krypterings script overfører jeg en nøgle fra databasen via ASP til JavaScipten, der variere hver gang. Det er rimligt primitivt, men jeg har generet en tabel med 510 udgaver af et rodet alfabet med et nummer og alfabet. Det overføres til klient scriptet nummeret bruges så til at identificere alfabetet igen når det indtastet skal dekrypteres. Så hvis man skal hacke det kræver at man netop sniffer en korrekt session med en registret bruger der logger ind, så en hacker ikke kan sidde og bryde nøglen ved at indtaste A B C osv i formen og derefter sniffe, det tilsvarende krypteret bogstav...
Ja, jeg vil forhindre en i at sniffe en korrekt login fra en registreret bruger. -Nøglen vil variere, random. Så hvis man er heldig nok skal man sniffe et korrekt login (brugernavn og password), så har man brug for den aktuelle nøgle ved det login, det befinder sig uheldigvis i en anden pakke, men kan findes.
Sikkerheden er ikke fatal, men bare rar at have... SSL er lige i overkanten. Jeg tror hjemmestrikket løsninger er de bedste da der ikke findes værktøjer til dem på nettet.
Synes godt om
Ny brugerNybegynder
Din løsning...
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.
