Hvorfor virker ACCEPT tag ikke på INPUT field?

Browsere behøver ikke implementere accept-parameteren. Gør det i hvert fald ikke.

Glem ikke at en hacker ikke behøver bruge en browser, og at du derfor yderligere skal kontrollere på serveren.

Det er fint nok at anvende accept-parameteren, for der er browsere der understøtter den (tror jeg nok), men der skal kontroleres serverside.

Skal under alle omstændigheder validere serverside. Man må ALDRIG stole på brugeren. Det er der så mange som bar brændt fingrene på at antage at man kan. Eller den gode gamle, "jamen vi validerer jo ude i browseren" ;-)

AHA!

Jamen jeg er RET sikker på at det HAR virket før!

Er det så fordi funktionaliteten er fjernet igen fra IE??

Og hvorfor? Skal det ikke understøttes mere?

Jeg synes det er en god pointe I har med at validere på serveren, MEN det ændrer jo ikke ved at så SKAL brugeren jo uploade først, hvilket tager tid samt lægger dum forkert fil unødigt på serveren, når det ligeså godt kunne undgås ved helt at spærre for det i klienten..!?
Men I mener altså ikke det kan lade sig gøre mere?

Og hvad er det som folk har brændt fingrene på?

<input type="file" ...> er et af de rigtigt grimme tags, rent sikkerhedsmæssigt. Der er mange ting man ikke kan, som man kan andre.

Derfor er det egentlig pænt af browserne at ignore accept-parameteren, fordi det ville give en falsk sikkerhedsfornemmelse. Om det er argumentet, ved jeg ikke - men det er praksis.

Kan det have noget at gøre med at jeg bruger Persits Upload komponent?

Nej - det er rent "server-side" - det ved browseren ikke noget om.

Husk også at det ikke hjælper en dyt at kontrollere om filtypen er "image/jpg" eller tilsvarende. Det er meganemt for en hacker at fuske med den ting. Man skal - ubetinget - også kontrollere extenseion, og det skal ske serverside.

Ja: extension. Fx.  .jpg

ok, hvis nu vi snakker hacker-problematikken..
SÅ kan han vel ikke gøre så meget hvis man
a) checker extension serverside efter upload (og i øvrigt sletter filen hvis den ikke har rette extension)
samt evt.
b) har sit upload bibliotek uden for websitets root bibliotek "www" ?

Du skal jo også passe meget på filnavnet. Ikke noget med at gemme den i det angivne filnavn før du har valideret at det navn faktisk er sikkert.

Det vil måske også være en god ide at sætte en øvre grænse for hvor store uploads der kan tillades for at undgå at en hacker fylder disken.

Hvad tænketr du på mht. filnavnet?
Og hvor ville du sætte filgrænsen? I form-feltets tag eller checke efter upload?

så man ikke lige pludselig får filnavne som skriver steder hvor den egentlig ikke skal skrive. Jeg kan ikke lige huske om det faktisk er en mulighed, men alligevel. Der kan også være filnavne som faktisk er for lange.

Filgrænsen sætter du på din upload serverside, således at den holder øje mens upload er i gang og kommer med en fejl til brugeren lige så snart grænsen er nået.

Mht filnavnet kan en hacker sætte et ascii-0-tegn ind, så filen i visse operativsystemer gemmes som det, der står før 0-tegnet, mens man måske har valideret extension efter 0-tegnet. Ydermere kan filnavnet indeholde "../../nogetandet", så det ikke gemmes i det forventede katalog. Derfor: find på et navn selv, eller strip navnet for tegn, man ikke vil have ... eller sådan noget ...

Vier godt nok kommet noget uden for topic nu, men interessant alligevel.
Hvilke operativsystemer har det problem med ascii-0?

Jeg kan ikke se ".." problemet. Man kan da ikke gemme i parent-bib, kan man?
Og desuden, så cheker jeg jo på filtypen, så selv OM de skulle ha fået adgang til at uploade en fil i et andet bib, så kan en lyd eller billedfil vel ikke skade?
Og desuden kan brugeren jo ikke få adgang til filer uden for root biblioteket www !?

Brugeren kan da i det hele taget slet ikek bestemme hvor filen skal gemmes??
Man kan jo kun vælge hvor den kopieres FRA? ikke sandt?

"Man kan da ikke gemme i parent-bib, kan man?" - jo, hvis tilladelserne er i orden. Det kan de jo være.

Men som du ser, er der mange ting at tage hensyn til. Fil-upload er et oplagt angrebssted for de søde små hackere.

Hvordan kan du "gemme" og selv bestemme destination (parent bib) når man jo kun har eet felt til rådighed som bruger, nemlig feltet hvor man vælger "FRA"/source filen?

Jeg tror du glemmer, at en hacker nok ikke ligefrem bruger en browser.

prøv at leg lidt med f.eks. perl og LWP modulet. Det har jeg før anvendt til at lave et nemmere interface til en webapplikation. Så kan man jo selv bestemme hvad det er man vil sende til applikationen uafh. af browseren.

Webdeveloper addon til FF er ganske nyttig til at analysere form's

Hej igen,

Det lyder som om I er velbevandret i erfaringer med temaet her.

Jeg bruger dog .ASP kode og Persits Upload komponent. Hvordan vil man kunne sikre imod ".." og ASCII-0 i et sådant setup?

Det nemmeste er at brugeren ikke selv får lov til at bestemme filnavnet på serveren.

Men ellers skal du kontrollere at hans filnavne kun indeholder lovlige tegn - eller som alternativ fjerne alle de ulovlige tegn.

<ole>

- og hvis du vil undgå at tabe kampen, skal du undlade at forsøge at definere, hvilke tegn, der er ulovlige!

Definer de lovlige tegn. Det er dem, du med sikkerhed ved, ikke kan gøre skade - f.eks. a-Z, 0-9, bindestreg, punktum og underscore. Alt andet er ulovligt og skal fjernes.

Selvom folk, der kander mig, nok ville beskrive min fantasi som (til tider lidt for) veludviklet og saftspændt, ville jeg aldrig turde stole på, den kan få mig til at komme i tanker om alle potentielt skadelige tegn. Det er langt lettere - og dermed sikrere - at definere, hvad der er lovligt  ;o)

/mvh
</bole>

Narkolovgivningen er i øvrigt et udmærket eksempel på denne problemstilling. Alle 'substanser' er lovlige, til de eksplicit er erklæret ulovlige.

Det er grundlaget for eksistensen af alle designerdrugs. Hvis en bestemt kemisk sammensætning gøres ulovlig, ændrer man blot en anelse på det grundlæggende molekyle - og man har et nyt stof.
Gøres det rigtigt, har man et stof med nogenlunde samme psykokemiske virkninger - men som det ofte ses med lidt ekstra, uforudsete 'gaver' ... f.eks. i form af Parkinsons-lignende syndromer.

Fra en lovgivningsmæssig vinkel ville det være meget lettere at sige: "Salt og sukker er lovligt - resten er der dødsstraf for!"

Jeg har heller ikke sagt - eh - ment andet. Du ulovlige tegn er defineret, som dem der ikke er lovlige. Mine to muligheder er:

1) Brokke sig til brugeren, hvis der ikke kun er lovlige tegn ("kontrollere at hans filnavne kun indeholder lovlige tegn")
2) Fjerne tegn, så der kun er lovlige tilbage, uden at brokke sig ("fjerne alle de ulovlige tegn")
2a) Ikke fjerne dem, men lave dem lidt om, fx til "_", og "ø" til "o", så filnavnet minder om det oprindelige. Så ender man heller ikke med et helt ulovlig filnavn :)

Jeg "kander" dig godt nok, Ole.

Godmorgen, Erik. Sku'ha'vær't: "Så ender man heller ikke med et helt tomt filnavn :)"

Jeg "kander" også dig godt nok til at vide, hvad du mente - men man ser desværre ofte folk prøve det modsatte ... altså at definere ulovlighederne  =)

ok, nu har jeg "streamet" min fil via et .asp script og henter den udefra www root, MEN jeg har opdaget at man alligevel blot kan skrive "../fil" oppe i url'en i browseren! Selv om jeg har fjernet kryds i "parent bibs" i IIS'en...
Såå hvordan kan det nu være? Og hvordan sikrer jeg at man ikke kan skrive www.mitsite.dk/../fil i URL'en??