mboost-dp1
Beta-test af selvbygger-blog
Hej,
Er der nogen der kunne tænke sig at teste min blog lidt?
http://www.jacobworsoe.dk/
Bare hack løs og se om I kan finde nogle fejl, eller ting der ikke virker ordentligt... Så må vi se om den er klar til at få fyldt noget indhold på den :)
På forhånd tak...
Er der nogen der kunne tænke sig at teste min blog lidt?
http://www.jacobworsoe.dk/
Bare hack løs og se om I kan finde nogle fejl, eller ting der ikke virker ordentligt... Så må vi se om den er klar til at få fyldt noget indhold på den :)
På forhånd tak...
Hvis det er det her du tænker på, så er det bare et screenshot:
http://www.jacobworsoe.dk/stuff/pause-start.jpg
http://www.jacobworsoe.dk/stuff/pause-start.jpg
illishar (4) skrev:Den spiser mine <>
Det er meningen, men bør nok lige skrives at det ikke er tilladt.
illishar (7) skrev:Alle RSS-entries henviser til
http://www.jacobworsoe.dk/overskrift-til-indlaegge...
Efter hvad jeg lige kan se så er der en enkelt kommentar der henviser til det andet indlæg. Men du har ret nemt ved at ødelægge mit rss-feed. Du kan nemt putte nogle tegn ind i det, som den slet ikke kan klare :)
illishar (8) skrev:Din script-blocker (Hvad er to + tre? (Skriv kun tal)) bliver lidt kedelig i længden. VILDERE REGNESTYKKER!
Ja, det ved jeg godt, men det har faktisk vist sig at være effektivt nok alligevel. Der er ikke sluppet noget igennem på de andre sider hvor jeg har brugt det. Så de små bots kan ikke regne den ud, selvom det er det samme hele tiden :)
Var nu nemt nok at finde ud af.Jace (13) skrev:Skal måske lige sige at det er i php...
http://www.jacobworsoe.dk/index.php retunere ikke en 404, det gør en anden invalid url.
Samt: http://www.jacobworsoe.dk/submit-comment.php
Skriv javascript:document.forms[0].submit(); i din urlbar, og du omgår dine Javascript checks.
Windcape (16) skrev:Det lykkes mig at tilføje et blank indlæg.
Jeg prøver lige at omskrive min server-side validering, så det ikke er muligt at lave tomme indlæg.
Windcape (15) skrev:Skriv javascript:document.forms[0].submit(); i din urlbar, og du omgår dine Javascript checks.
.submit();]http://www.jacobworsoe.dk/overskrift-til-indlaegget-12/javascript:document.forms[0].submit();
Sådan her? Ellers forstår jeg ikke helt hvad du mener?
Windcape (17) skrev:Det er nok ikke så smart at tillader javascript: i din url input.
Kan du hjælpe mig med hvordan jeg undgår at man kan det?
Jace (9) skrev:Det er meningen, men bør nok lige skrives at det ikke er tilladt.
Trækker stort ned. Ikke bare fordi man ikke kan skrive tegnene, men det fortæller alt hvad jeg har behov for at vide om din sikkerhedsmodel. Senere kommenterer i denne tråd bekræfter det.
Hvis man betrager "<" og ">" som farlige tegn, så har man totalt misforstået hvordan man laver sikkerhed.
Nu har jeg testet den kommentar-funktion lidt, og den er da helt gal. Jeg tror at hele turen fra man skriver noget, til det bliver vist på skærmen igen, er noget du lige skal tænke igennem helt fra starten.
Jeg foreslår noget i denne stil:
En masse tegn bliver accepteret som de er. Bogstaver, tal og almindelig tegnsætning. Måske findes der et eller andet standard til PHP som kan fjerne farlige tegn, da det er ret svært at lave en komplet whitelist.
De "farlige tegn" < > & og evt. " og ' laver du til HTML entities. (< osv.)
Linjeskift sætter du <br /> foran. (Husk at der er 3 slags linjeskift at tage hensyn til: \r\n, \n og \r)
Så mangler du vist bare at håndtere fjollet indholdet. Fx. mine 500 X'er i træk, 500 linjeskift i træk og sådan noget. Fx. kan du lave en div med max-størrelser og overflow:auto som et godt udgangspunkt.
Jeg foreslår noget i denne stil:
En masse tegn bliver accepteret som de er. Bogstaver, tal og almindelig tegnsætning. Måske findes der et eller andet standard til PHP som kan fjerne farlige tegn, da det er ret svært at lave en komplet whitelist.
De "farlige tegn" < > & og evt. " og ' laver du til HTML entities. (< osv.)
Linjeskift sætter du <br /> foran. (Husk at der er 3 slags linjeskift at tage hensyn til: \r\n, \n og \r)
Så mangler du vist bare at håndtere fjollet indholdet. Fx. mine 500 X'er i træk, 500 linjeskift i træk og sådan noget. Fx. kan du lave en div med max-størrelser og overflow:auto som et godt udgangspunkt.
arne_v (19) skrev:#18
Generelt er det bedre at teste positivt end negativt d.v.s. at du skal teste om noget matcher det du betragter som lovligt input fremfor at teste om det matcher det du betragter som ulovligt.
Okay, det vil jeg lige prøve at tænke ind i det. Tak for det.
myplacedk (22) skrev:Nu har jeg testet den kommentar-funktion lidt, og den er da helt gal. Jeg tror at hele turen fra man skriver noget, til det bliver vist på skærmen igen, er noget du lige skal tænke igennem helt fra starten.
Mange tak for din lange kommentar - super fedt at du gider!
Jeg vil lige prøve at gennemtænke hele processen igen forfra, og vende tilbage når jeg har et nyt forsøg :)
Jace (24) skrev:Kan du hjælpe med hvordan man undgår det?
Det kan du ikke undgå. Du skal bare vide, at clientside (dvs. javascript validering) er "flødeskum", noget der kun er der for brugerens skyld. Du er nødt til at lave de samme kontroller serverside.
Det eneste formål dit javascript har (eller må have), er at brugeren får hurtigere besked, fordi det ikke skal omkring serveren.
myplacedk (26) skrev:Det kan du ikke undgå. Du skal bare vide, at clientside (dvs. javascript validering) er "flødeskum", noget der kun er der for brugerens skyld. Du er nødt til at lave de samme kontroller serverside.
Det eneste formål dit javascript har (eller må have), er at brugeren får hurtigere besked, fordi det ikke skal omkring serveren.
Jeg kan huske at arne_v tidligere har sagt: "client-side for convenience - server-side for security". Det opsummerer vist meget godt hvad forskellen er :)
Så er der bare lige det der med hvad man skal gøre hvis server-side validering fejler. Så skal brugeren jo sendes tilbage og felterne skal udfyldes automatisk, så brugeren ikke skal udfylde alle felter igen.
Lige nu ser mit flow således ud:
- brugeren indtaster i formen på post.php og bliver sendt til submit.php
- submit.php tjekker input og indsætter i database og sender brugeren tilbage til post.php via header(location)
Men jeg overvejer lidt at lave det således at det hele sker på post.php, så det er nemmere at udfylde felterne igen uden at man skal igang med noget session-halløj, for at overføre mellem de to sider.
Men så står man bare med problemet at hvis brugeren trykker F5, så bliver POST sendt igen. Så jeg plejer at lave en redirect til sidst, så det ikke sker. Hvilken løsning foretrækker I at lave?
Lige nu ser mit flow således ud:
- brugeren indtaster i formen på post.php og bliver sendt til submit.php
- submit.php tjekker input og indsætter i database og sender brugeren tilbage til post.php via header(location)
Men jeg overvejer lidt at lave det således at det hele sker på post.php, så det er nemmere at udfylde felterne igen uden at man skal igang med noget session-halløj, for at overføre mellem de to sider.
Men så står man bare med problemet at hvis brugeren trykker F5, så bliver POST sendt igen. Så jeg plejer at lave en redirect til sidst, så det ikke sker. Hvilken løsning foretrækker I at lave?
Jace (30) skrev:Men jeg overvejer lidt at lave det således at det hele sker på post.php, så det er nemmere at udfylde felterne igen uden at man skal igang med noget session-halløj, for at overføre mellem de to sider.
I din situation, hvis vi ser helt isoleret på dette problem, ville jeg nok submitte til samme side som man er på, og så redirecte hvis handlingen udføres successfuld.
Men som Windcape overlader jeg normalt den slags til et eller andet framework.
Jace (30) skrev:Men så står man bare med problemet at hvis brugeren trykker F5, så bliver POST sendt igen. Så jeg plejer at lave en redirect til sidst, så det ikke sker. Hvilken løsning foretrækker I at lave?
Det vil løse noget af det, men man vil stadig kunne lave dobbelt-submit ved et uheld. Du kan tjekke på om præcist den samme kommentar allerede er i databasen. Eller have et id i et skjult felt i formen, som skal matche et id i sessionen for at man kan submitte. Når handlingen så er udført fjerner du id'et fra sessionen, og formen er nu ugyldig.
Men igen, det kan et framework nemt klare.
myplacedk (33) skrev:Det vil løse noget af det, men man vil stadig kunne lave dobbelt-submit ved et uheld. Du kan tjekke på om præcist den samme kommentar allerede er i databasen. Eller have et id i et skjult felt i formen, som skal matche et id i sessionen for at man kan submitte. Når handlingen så er udført fjerner du id'et fra sessionen, og formen er nu ugyldig.
Også kendt som:
Synchronizer Token pattern
I Java EE.arne_v (35) skrev:Også kendt som:
Synchronizer Token pattern
Jeg har faktisk ikke set nogen som har brugt den model i PHP. Typisk benyttes routing og RESTful style URLs til at matche routes.
Jeg ved ihvertfald at ASP.NET MVC, Zend og CakePHP benytter routes.
Jeg kan i øvrigt anbefale dig at læse op på lidt patterns. Enten på nettet eller en eller anden mere eller mindre pædagogisk bog, alt efter hvad du foretrækker. Jeg linker her til Wikipedia, men det er ret overfladisk hvad du finder der. Jeg har bøger stående hvor hvert pattern er et helt kapitel.
Jeg tænker først på model–view–controller, da jeg lige har undervist i et framework baseret på det pattern.
Og så synes jeg layers er vigtig for at få sikkerhedsmodellen på plads. Jeg kan godt lide at tage udgangspunkt i dette pattern, når vi snakker om fx. hele problematikken med kommentarer, hvor det jo både skal være sikkert og se godt ud.
Jeg tænker først på model–view–controller, da jeg lige har undervist i et framework baseret på det pattern.
Og så synes jeg layers er vigtig for at få sikkerhedsmodellen på plads. Jeg kan godt lide at tage udgangspunkt i dette pattern, når vi snakker om fx. hele problematikken med kommentarer, hvor det jo både skal være sikkert og se godt ud.
Windcape (36) skrev:I Java EE.
Den er opfundet der.
Windcape (36) skrev:Jeg har faktisk ikke set nogen som har brugt den model i PHP.
Jeg har heller aldrig hørt om det i PHP. Men jeg har hært om det i ASP.NET.
Windcape (36) skrev:Typisk benyttes routing og RESTful style URLs til at matche routes.
Det beskytter ikke mod det som Synchronizer Token beskytter mod.
Så har jeg fået omskrevet hele balladen, så den forhåbentlig er lidt bedre sikret :)
Rettet - der bliver lavet et nyt regnestykke hver gang. Bliver tjekket server-side og man får en alert-box hvis det er forkert.
Rettet - Det bliver nu også testet server-side om alle felter er udfyldt, og man får en alert hvis de ikke er.
Rettet - < og > bliver lavet til html entities.
Jeg bruger nl2br($comment), så det burde fungere.
Jeg har lavet en div med width=1000 og så overflow:auto, så dine X'er ikke ødelægger noget. Det med 500 linjeskift skal jeg lige have kigget på. Jeg kan ikke rigtigt sætte en height=500 på div'en da den så altid vil have den størrelse, selv hvis der kun skrives en linje.
Alting kører nu på samme side, med redirect til sidst.
Rettet, så den tjekker om kommentar, navn og mail allerede er i databasen. Man får en alert hvis den allerede er lavet.
Det var vist det - så hvis I gider må I gerne køre det tunge hacking-skyts frem igen og se hvor meget den kan holde til denne gang :)
På forhånd tak.
illishar (8) skrev:Din script-blocker (Hvad er to + tre? (Skriv kun tal)) bliver lidt kedelig i længden. VILDERE REGNESTYKKER!
Rettet - der bliver lavet et nyt regnestykke hver gang. Bliver tjekket server-side og man får en alert-box hvis det er forkert.
Windcape (16) skrev:Det lykkes mig at tilføje et blank indlæg.
Rettet - Det bliver nu også testet server-side om alle felter er udfyldt, og man får en alert hvis de ikke er.
myplacedk (22) skrev:De "farlige tegn" < > & og evt. " og ' laver du til HTML entities. (< osv.)
Rettet - < og > bliver lavet til html entities.
myplacedk (22) skrev:Linjeskift sætter du <br /> foran. (Husk at der er 3 slags linjeskift at tage hensyn til: \r\n, \n og \r)
Jeg bruger nl2br($comment), så det burde fungere.
myplacedk (22) skrev:Så mangler du vist bare at håndtere fjollet indholdet. Fx. mine 500 X'er i træk, 500 linjeskift i træk og sådan noget. Fx. kan du lave en div med max-størrelser og overflow:auto som et godt udgangspunkt.
Jeg har lavet en div med width=1000 og så overflow:auto, så dine X'er ikke ødelægger noget. Det med 500 linjeskift skal jeg lige have kigget på. Jeg kan ikke rigtigt sætte en height=500 på div'en da den så altid vil have den størrelse, selv hvis der kun skrives en linje.
myplacedk (33) skrev:I din situation, hvis vi ser helt isoleret på dette problem, ville jeg nok submitte til samme side som man er på, og så redirecte hvis handlingen udføres successfuld.
Alting kører nu på samme side, med redirect til sidst.
myplacedk (33) skrev:Det vil løse noget af det, men man vil stadig kunne lave dobbelt-submit ved et uheld. Du kan tjekke på om præcist den samme kommentar allerede er i databasen.
Rettet, så den tjekker om kommentar, navn og mail allerede er i databasen. Man får en alert hvis den allerede er lavet.
Det var vist det - så hvis I gider må I gerne køre det tunge hacking-skyts frem igen og se hvor meget den kan holde til denne gang :)
På forhånd tak.
Ser godt ud! Thumbs up!
Næste skridt er flood protection. Lange indlæg (i bytes), lange indlæg (i linjer) og jeg vil gætte på at du heller ikke beskytter mod at én person skriver 1000 indlæg lige efter hinanden (ud over regnestykket).
Men så nærmer vi os et punkt hvor du nok hellere vil have moderering alligevel. Systemet kan aldrig blive perfekt med automatisk validering alligevel.
Næste skridt er flood protection. Lange indlæg (i bytes), lange indlæg (i linjer) og jeg vil gætte på at du heller ikke beskytter mod at én person skriver 1000 indlæg lige efter hinanden (ud over regnestykket).
Men så nærmer vi os et punkt hvor du nok hellere vil have moderering alligevel. Systemet kan aldrig blive perfekt med automatisk validering alligevel.
Man kan skrive tegnet (ASCII 160) i felterne og lave en tilsyneladende helt tom kommentar.
Hvis det er et krav at man skal skrive en e-mail burde der vel også være validering på det felt?
Ved godt det kan ske i få tilfælde, men det burde vel heller ikke kunne lade sig gøre pga. regnestykke-checket?
Hvis det er et krav at man skal skrive en e-mail burde der vel også være validering på det felt?
Jace (40) skrev:myplacedk (33) skrev:Det vil løse noget af det, men man vil stadig kunne lave dobbelt-submit ved et uheld. Du kan tjekke på om præcist den samme kommentar allerede er i databasen.
Rettet, så den tjekker om kommentar, navn og mail allerede er i databasen. Man får en alert hvis den allerede er lavet.
Ved godt det kan ske i få tilfælde, men det burde vel heller ikke kunne lade sig gøre pga. regnestykke-checket?
myplacedk (42) skrev:Næste skridt er flood protection. Lange indlæg (i bytes), lange indlæg (i linjer) og jeg vil gætte på at du heller ikke beskytter mod at én person skriver 1000 indlæg lige efter hinanden (ud over regnestykket).
Jeg har rettet det med 500 linjeskift. Jeg synes dog det er svært at sætte en grænse for at en person må skrive lange indlæg. Men hvis det er en bot der gør det, så skal det selvfølgelig stoppes. Men det skulle antispam gerne ordne :)
Hvis jeg skriver "www.test.dk" i URL feltet laver den et link til "http://www.jacobworsoe.dk/overskrift-til-indlaegget-12/www.test.dk"
Hvis jeg går ind på en nyhed, og derefter åbne en ny tab med samme nyhed. Så fungere formen på første nyhed ikke pga. antispam. Det er ikke nok at gemme den sidst-opdaterede side pr. IP.
Hvis jeg går ind på en nyhed, og derefter åbne en ny tab med samme nyhed. Så fungere formen på første nyhed ikke pga. antispam. Det er ikke nok at gemme den sidst-opdaterede side pr. IP.
m910q (43) skrev:Man kan skrive tegnet (ASCII 160) i felterne og lave en tilsyneladende helt tom kommentar.
Ja, det skal jeg lige have rettet så man ikke kan det, da det også gør at RSS-feedet ikke validerer. Jeg ved dog ikke lige hvordan jeg skal gøre det :) Ved du hvordan man kan gøre det?
m910q (43) skrev:Hvis det er et krav at man skal skrive en e-mail burde der vel også være validering på det felt?
Rettet, så den tjekker om kommentar, navn og mail allerede er i databasen. Man får en alert hvis den allerede er lavet.
Ved godt det kan ske i få tilfælde, men det burde vel heller ikke kunne lade sig gøre pga. regnestykke-checket? [/quote]
Joh, jeg får lige lavet, så den tjekker om det er en valid e-mail man skriver, så man ikke bare kan skrive hvad som helst i feltet.
Nej, jeg tror også regnestykket sørger for at det ikke sker. Altså udover det tilfælde hvor man får det samme regnestykke to gange i træk. Men når I trykker F5 efter at have postet, så bliver den ikke posted igen, vel? Jeg kan ikke få den til at gøre det, så jeg tror ikke det giver nogen problemer.
Cloud02 (44) skrev:En nummerering af kommentarer vil ikke være skidt. Så kan man lave referencer med sine kommenteringer. Evt. også med anchor points.
Rettet - skal nok lige lave det lidt pænere i morgen :)
Cloud02 (44) skrev:Jeg må indrømme at jeg er lidt ærgerlig over at man ikke længere kan skrive html og benytter ting som fed, kursiv og blockquote.
Jeg prøver at tillade html i kommentar-feltet. Så må vi se om det bliver udnyttet - men det skal jeg måske ikke være bange for at det bliver?
Din rewrite eller hvad de nu bruger, mangler lidt. Man kan finde ud af hvilke mapper du har i roden.
Webserver standard 404:
www.jacobworsoe.dk/hest
Din egen fejlside:
www.jacobworsoe.dk/hest/
Din egen fejlside pga. mappen findes:
www.jacobworsoe.dk/stuff
Webserver standard 404:
www.jacobworsoe.dk/hest
Din egen fejlside:
www.jacobworsoe.dk/hest/
Din egen fejlside pga. mappen findes:
www.jacobworsoe.dk/stuff
m910q (46) skrev:Hvis jeg skriver "www.test.dk" i URL feltet laver den et link til "http://www.jacobworsoe.dk/overskrift-til-indlaegget-12/www.test.dk"
Ja, det har jeg godt lagt mærke til. Det er fordi man SKAL skrive den fulde adresse med http:// foran - ellers tror den at det er en intern side på mit site du linker til. Jeg har rettet det og skrevet at man skal huske http:// foran, men det kan godt være jeg bliver nødt til at lave et check og se om man har husket at skrive det og ellers putte det på automatisk.
m910q (46) skrev:Hvis jeg går ind på en nyhed, og derefter åbne en ny tab med samme nyhed. Så fungere formen på første nyhed ikke pga. antispam. Det er ikke nok at gemme den sidst-opdaterede side pr. IP.
Jeg har lavet det så den værdi som regnestykke skal give bliver gemt i en SESSION variabel når de to tal bliver lavet tilfældigt. Når man så submitter formen, så tjekker jeg det man indtaster med det som ligger i SESSION variablen. Det gør, som du er inde på, at man ikke kan have to nyheder åbne på en gang og skrive kommentarer til dem begge - og det er jo noget rod at man ikke kan det :) Men hvordan kan jeg ellers gemme den variablen som jeg skal tjekke op mod?
Gå til top
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
- ⟨
- Programmering
Gå til bund