mboost-dp1
SXC - clix
huh? Det ser da helt fint ud
- "Improper Input Validation"
- "Failure to Preserve SQL Query Structure"
- "Cleartext Transmission of Sensitive Information"
- "Cross-Site Request Forgery"
- "Error Message Information Leak" - Adgangskoder i fejlkoder
- "Failure to Constrain Operations within the Bounds of a Memory Buffer"
- "Execution with Unnecessary Privileges"
Samt mange andre... De er utrolig nemme at forstå.
- "Improper Input Validation"
- "Failure to Preserve SQL Query Structure"
- "Cleartext Transmission of Sensitive Information"
- "Cross-Site Request Forgery"
- "Error Message Information Leak" - Adgangskoder i fejlkoder
- "Failure to Constrain Operations within the Bounds of a Memory Buffer"
- "Execution with Unnecessary Privileges"
Samt mange andre... De er utrolig nemme at forstå.
Alle de punkter der er nævnt har et nr. f.eks. CWE-426:Untrusted Search Path med en hurtig google søgning giver det http://cwe.mitre.org/data/definitions/426.html der er en uddybet forklaring af det.
F.eks. denne her "CWE-327:Use of a Broken or Risky Cryptographic Algorithm"
Der siges såmend bare at du ikke skal stole på md5 som kryptering, da den er for nemt at bryde, både med rainbow tables, og med brute-force.
Der siges såmend bare at du ikke skal stole på md5 som kryptering, da den er for nemt at bryde, både med rainbow tables, og med brute-force.
Folk læser vel forhåbenlig hele artiklen? Eller i det mindste, scroller det hele igennem.LordMike (7) skrev:Mht. dem der ikke forstår det, kan det skyldes at listen er i bunden ?... Dvs, ikke i toppen som primært indhold, hvor man forventer den, men mere som bilag.
#10 SHA256 har en god balance i udbredthed og sikkerhed - men der er med garanti et par kloge hoveder herinde der har nogle dybt teoretiske grunde til at det heller ikke er godt nok.
Tænk at være den programmør som "opfandt" disse sikkerhedsfejl.
sidder der i sit værelse og hamrer løs på sit tastatur for at programmere god kode, ifølge ham, og senere opdager at hans kode er blandt de 25 absolut værste.
Så er det man tænker om det nu også var en god ide at drikke de 4 liter Cola på 1 time.
sidder der i sit værelse og hamrer løs på sit tastatur for at programmere god kode, ifølge ham, og senere opdager at hans kode er blandt de 25 absolut værste.
Så er det man tænker om det nu også var en god ide at drikke de 4 liter Cola på 1 time.
#13 Jeg tror netop ikke at der kun er een opfinder af disse fejl. Det er rimelig gennemgående at mange programmører elsker selv at opfinde den dybe tallerken (De andres er sværre at forstå eller bare ikke "født her"). Listen af top-fejl er bare en angivelse af faldgrupper som rigtig mange programmører falder i, når de skal opfinde deres nye tallerken.
Hvis man gerne vil se praktiske eksempler på fejlene, så kan www.thedailywtf.com anbefales...;)
Her er et fint eksempel på den sidste, "CWE-602:Client-Side Enforcement of Server-Side Security":
http://thedailywtf.com/Articles/Security_101__0x2e...
Her er et fint eksempel på den sidste, "CWE-602:Client-Side Enforcement of Server-Side Security":
http://thedailywtf.com/Articles/Security_101__0x2e...
#17 Denne liste er ment til at være praktisk anvendelig. Og som sådan skal man jo vælge en balance mellem at offentliggøre nok fejl til at du ender med et relativt sikkert program, og ikke at offentliggøre en alt for lang liste som ender med at virke uoverskuelig(og derfor ikke taget alvorligt ved faktisk udvikling).
Hvis du sidder i et større projekt med mange mb kode, er der langt større chance for at firmaet bag vil bruge ressourcer på at checke for 25 fejl, modsat fx 100 eller 200 fejl. Specielt dem der kræver manuel testing.
Syntes at det er god liste, der er abstrakt nok til at ramme stort set alle og alligevel specifik nok til at man meget præcist kan finde de dele af ens egen kode hvor i fejlen evt kunne være(hvis den er der).
Hvis du sidder i et større projekt med mange mb kode, er der langt større chance for at firmaet bag vil bruge ressourcer på at checke for 25 fejl, modsat fx 100 eller 200 fejl. Specielt dem der kræver manuel testing.
Syntes at det er god liste, der er abstrakt nok til at ramme stort set alle og alligevel specifik nok til at man meget præcist kan finde de dele af ens egen kode hvor i fejlen evt kunne være(hvis den er der).
#10 og #11
Jeg havde nok valgt at bruge en SHA hash (her tænker jeg mest på SHA-128, SHA-256 eller SHA-512) inklusiv SALT.
SALTs har den glimrende fordel at de gør rainbow table attacks ubrugelige, selv hvis en potentiel hacker får fat i din SALT, hvilket i øvrigt også er utænkeligt.
Men det er vigtigt at bemærke at ALLE hash kan brydes med brute force. Spørgsmålet er bare hvor længe dette tager, og hvor let det er for en hacker at gennemskue hvordan hashen skal brute forces.
Jeg havde nok valgt at bruge en SHA hash (her tænker jeg mest på SHA-128, SHA-256 eller SHA-512) inklusiv SALT.
SALTs har den glimrende fordel at de gør rainbow table attacks ubrugelige, selv hvis en potentiel hacker får fat i din SALT, hvilket i øvrigt også er utænkeligt.
Men det er vigtigt at bemærke at ALLE hash kan brydes med brute force. Spørgsmålet er bare hvor længe dette tager, og hvor let det er for en hacker at gennemskue hvordan hashen skal brute forces.
Jeg har ikke programmeret i 6 år, og dengang var det simple websites.
Kan ikke forstå hvorfor den liste skulle være så svær at forstå...
Og det er da slet ikke nyt, og meget af det burde være ren logik, især CWE-602!
Syntes det er et godt initiativ, at det bliver mere udbredt viden, og føler man ikke man forstår det, så syntes jeg personligt at man burde tage udfordringen op, og lære det, for derved at blive en bedre programmør.
Kan ikke forstå hvorfor den liste skulle være så svær at forstå...
Og det er da slet ikke nyt, og meget af det burde være ren logik, især CWE-602!
Syntes det er et godt initiativ, at det bliver mere udbredt viden, og føler man ikke man forstår det, så syntes jeg personligt at man burde tage udfordringen op, og lære det, for derved at blive en bedre programmør.
#8
MD5 er absolut ikke nem at bruteforce. 100 millioner checks per sekund og 1 milliard computere => 100000 milliarder år.
Og p.g.a. det store udfaldsrum kan man ikke lave komplette rainbow tables. Dictionary attacks er selvfølgelig mulige.
Problemet med MD5 er, at der er fundet alvorlige kryptografiske svagheder i den, som gør det meget nemt at generere kollisioner.
MD5 er absolut ikke nem at bruteforce. 100 millioner checks per sekund og 1 milliard computere => 100000 milliarder år.
Og p.g.a. det store udfaldsrum kan man ikke lave komplette rainbow tables. Dictionary attacks er selvfølgelig mulige.
Problemet med MD5 er, at der er fundet alvorlige kryptografiske svagheder i den, som gør det meget nemt at generere kollisioner.
#20
Problemet er ikke så meget viden om fejl typerne. Jeg vil gætte på at i 80% af tilfældene med fejl så kender udviklerne godt den generelle fejl.
Problemet er at sikre sig at der aldrig (eller næsten aldrig) smutter nogle af fejlene igennem.
Det er den reelle problem stilling. Og den er deværre langt vanskeligere at løse.
Problemet er ikke så meget viden om fejl typerne. Jeg vil gætte på at i 80% af tilfældene med fejl så kender udviklerne godt den generelle fejl.
Problemet er at sikre sig at der aldrig (eller næsten aldrig) smutter nogle af fejlene igennem.
Det er den reelle problem stilling. Og den er deværre langt vanskeligere at løse.
Et godt link er http://www.sans.org/top25errors/#s4. Her kan man se beskrivelser af alle fejlene på en gang.
#24
Du har ret - der var jeg en smule for hurtig ved tastaturet;D
#25
Der ville jeg nok typisk bruge både en random salt og en hemmeligholdt salt af grundlæggende tre årsager:
1) Det er højst usandsynligt at en potentiel hacker får fat i både databasen og source filen hvor den hemmeligholdte salt opbevares.
2) Det tager længere tid at brute force, selv hvis en hacker finder frem til den hemmeligholdte salt.
3) Og bruger random salts til at sikre at to ens passwords vil fremstå meget forskelligt i databasen, hvilket sikrer at en potentiel hacker ikke kan lave fælles brute force for flere brugere af gangen.
#26
Jeg er fuldkommen enig!
Du har ret - der var jeg en smule for hurtig ved tastaturet;D
#25
Der ville jeg nok typisk bruge både en random salt og en hemmeligholdt salt af grundlæggende tre årsager:
1) Det er højst usandsynligt at en potentiel hacker får fat i både databasen og source filen hvor den hemmeligholdte salt opbevares.
2) Det tager længere tid at brute force, selv hvis en hacker finder frem til den hemmeligholdte salt.
3) Og bruger random salts til at sikre at to ens passwords vil fremstå meget forskelligt i databasen, hvilket sikrer at en potentiel hacker ikke kan lave fælles brute force for flere brugere af gangen.
#26
Jeg er fuldkommen enig!
Med bruteforce mente jeg også det at udnytte hash collisions.arne_v (21) skrev:#8
MD5 er absolut ikke nem at bruteforce. 100 millioner checks per sekund og 1 milliard computere => 100000 milliarder år.
Det umidbare formål er jo præcist det samme, som jeg har forstået det.
#26
SHA hash er noget af det mest brugte, så jeg går ikke udfra det er det du mener.
Tror ikke der er mange programmeringssprog tilbage der har md5 funktioner men ikke tilsvarende SHA256/SHA512 funktioner.
SHA hash er noget af det mest brugte, så jeg går ikke udfra det er det du mener.
Tror ikke der er mange programmeringssprog tilbage der har md5 funktioner men ikke tilsvarende SHA256/SHA512 funktioner.
Jeg synes #27 har en vigtig pointe. Mener at huske nogle ulykker med diverse raketter hvor fejlagtig konvertering mellem variable eller en 32 bit integer der pludselig fik en vaerdi paa mere en 32 bit gav nogle uheldige ulykker.
Fx.: http://en.wikipedia.org/wiki/Ariane_5_Flight_501
Var der ikke ogsaa noget med Excel der havde en mystisk fejl, hvilket gjorde at et stoerre selskab pludselig havde en enorm tilsyneladende regnefejl i deres budgetter.
Eller den gode gammeldags buffer overflow fejl, et evigt loop der laegger et system ned, index out of range, etc. etc.
Anyway, jeg vil sku noedigt have en Ariana raket i hovedet fordi en uheldig/dum programmoer begaar en basal fejl, der desvaerre foerst opdages runtime under et helt saerligt scenarie.
Fx.: http://en.wikipedia.org/wiki/Ariane_5_Flight_501
Var der ikke ogsaa noget med Excel der havde en mystisk fejl, hvilket gjorde at et stoerre selskab pludselig havde en enorm tilsyneladende regnefejl i deres budgetter.
Eller den gode gammeldags buffer overflow fejl, et evigt loop der laegger et system ned, index out of range, etc. etc.
Anyway, jeg vil sku noedigt have en Ariana raket i hovedet fordi en uheldig/dum programmoer begaar en basal fejl, der desvaerre foerst opdages runtime under et helt saerligt scenarie.
Windcape (5) skrev:huh? Det ser da helt fint ud
- "Improper Input Validation"
- "Failure to Preserve SQL Query Structure"
- "Cleartext Transmission of Sensitive Information"
- "Cross-Site Request Forgery"
- "Error Message Information Leak" - Adgangskoder i fejlkoder
- "Failure to Constrain Operations within the Bounds of a Memory Buffer"
- "Execution with Unnecessary Privileges"
Samt mange andre... De er utrolig nemme at forstå.
Nu tror jeg ikke at det er fordi man har egenskaben at læse indenad at det er det som de siger.
Men nok snare at nogle af disse fejl kan opstår når du passerer variabler mellem platforme som gør at de nogle gange kan opsnappes og der ved misbruges.
Et eks.
Du har en Sql klasse som håndtere alt Sql kommunikation.
Du har så lavet et SQL login for at give brugen mulighed af at vælge DB type uanset udgiver at Databasen IBM, Microsoft MySQL osv.
denne klasse er en af dine topklasser hvor at alt information om din SQL forbindelse står i.
Nu har du så en masse Underklasser og dialoger med klasser tilhørende disse dialoger.
Det du så gør er at dit Login Dialog vindue sender Data til SQL klassen som bruger det til at skabe forbindelse mellem dit program og selve databasen.
Din hoved dialog henter så definitionen af din SQL klassen, og bruger den videre ned gennem systemet, men da du ikke bruger indkryptering af dit password eller bruger navn, vil din SQL klasse definition sikkert ligge oppe i starten af den dedikeret hukommelse som dit programmel bruger.
Dette gør at hvis du så laver en Hook som går ind og griber fat i Windows Kernel og der efter forspørger på hvilke processer der køre vil dit program også dukke op.
Nu er det bare at scanne hukommelsen igennem for denne sql klasse, og her vil du så have Password og brugernavn.
Nu kan du så lave en orm der søger via Hooks i Kernelen efter dit program og der efter scanner den blok hukommelse som er der hvor programmet allokere Bruger navn og password.
Samme teori kan man bruge på andre programmer Bla Outlook og FTP programmer.
Er det en fejl i programmeringen ?
Man kunne lave en ny instance af klassen hvergang man havner i en anden klasse der ved få Sqlklassen til at rygge rundt i det hukommelses område tildelt dit program.
Problemet er her at det er spild af hukommelse og kan resultere i Mem leaks, plus at du resikere pga dårlig Garbage collection at password og brugernavn står der flere steder.
Eller man kunne lave en lille simplet indkryptering af sine variabler så de ikke står som klar tekst, behøver ikke at være en eller anden 512 bit kryptering, kan sagtens lave en kryptering som vil give problemer for de fleste, som sikkert ikke er på mange bit.
Det korte og lange i dette indlæg er at, PGA. dårlig superbruger politik er det tit havned hos programmøren at han hun skal komme med en løsning til problemet at Password ikke er skiftet siden ruder konge ikke engang var en erotisk tanke i sin fars underbukser.
Jeg tror ikke at stærke encrypteringer er problemet.
Eks.
Når du laver et program gør du det at hvergang du starter programmet laver du en kyptering basseret på tiden & brugeren.
Der ved skal ham som hacker sig ind via dit program eller via orm som sniffer i dit program efter password og bruger info.
Både kende programmet men samtidig vide hvem det er der logger sig ind, samtidig hvornår han logger ind.
Ergo vil man have en faktor som ændre sig hele tiden, og er forholdsvis uforudsiglig og dette vil i sig selv gøre krypteringen stærk.
Eks.
Når du laver et program gør du det at hvergang du starter programmet laver du en kyptering basseret på tiden & brugeren.
Der ved skal ham som hacker sig ind via dit program eller via orm som sniffer i dit program efter password og bruger info.
Både kende programmet men samtidig vide hvem det er der logger sig ind, samtidig hvornår han logger ind.
Ergo vil man have en faktor som ændre sig hele tiden, og er forholdsvis uforudsiglig og dette vil i sig selv gøre krypteringen stærk.
#39
En ideel løsning ville være ODBC, så ens application aldrig nogen sinde har hardkodet passwords.
Jeg oplevede noget lign. da jeg kodede en ftp upload til mit website. Jeg så mit password i en debug stacktrace, og gik straks i panikmode.
Fik sørget for at det blev vel beskyttet, så de ikke kunne dukke op i en stacktrace -- selvom jeg gerne så at der slet ikke KOM en public stacktrace.
Better safe than sorry.
En ideel løsning ville være ODBC, så ens application aldrig nogen sinde har hardkodet passwords.
Jeg oplevede noget lign. da jeg kodede en ftp upload til mit website. Jeg så mit password i en debug stacktrace, og gik straks i panikmode.
Fik sørget for at det blev vel beskyttet, så de ikke kunne dukke op i en stacktrace -- selvom jeg gerne så at der slet ikke KOM en public stacktrace.
Better safe than sorry.
#42: Det er altså noget sludder.
Og brute force er ikke noget du bryder, men en fremgangsmåde.
Det svarer til at du vil bestille en pizza, uden at kende nummeret. For at finde det rigtige nummer, starter du med 00000001, så 00000002, indtil du rammer det rigtige nummer. Men det rigtige nummer er 86123661, så du nødt til at afprøve 86123661 forskelige numre for at finde det rigtige. Du kan evt udnytte kenskab til telefonnumres opbygning for at sætte farten op, men det er stadig pæænt mange numre at afprøve.
Og brute force er ikke noget du bryder, men en fremgangsmåde.
Det svarer til at du vil bestille en pizza, uden at kende nummeret. For at finde det rigtige nummer, starter du med 00000001, så 00000002, indtil du rammer det rigtige nummer. Men det rigtige nummer er 86123661, så du nødt til at afprøve 86123661 forskelige numre for at finde det rigtige. Du kan evt udnytte kenskab til telefonnumres opbygning for at sætte farten op, men det er stadig pæænt mange numre at afprøve.
#43
Det er et godt eksempel.
Men hvis du kender telefonnummer opbygning, f.eks. ved hvad der er mobilnumre, så er det ikke bruteforce længere.
Det er et godt eksempel.
Men hvis du kender telefonnummer opbygning, f.eks. ved hvad der er mobilnumre, så er det ikke bruteforce længere.
#41
ODBC garanterer ikke imod hardcoded passwords.
Du kan have:
* password i connection string
* password gemt sammen med DSN info (registry ??)
* bruge Windows authentication
Kun det sidste undgår password.
Men ikke alle databaser understøtter det. Og ikke alle konfigurationer muliggør det.
ODBC garanterer ikke imod hardcoded passwords.
Du kan have:
* password i connection string
* password gemt sammen med DSN info (registry ??)
* bruge Windows authentication
Kun det sidste undgår password.
Men ikke alle databaser understøtter det. Og ikke alle konfigurationer muliggør det.
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Nyheder
Gå til bund