Funktion för att ta bort dumma tecken från filnamn innan uppladdning?

Jag har en filuppladdning men filerna som laddas upp kan döpas hursomhelst. Man kan ju lösa detta med ex Regex men då måste man veta allt man vill filtrera bort eller så blir det nya namnet inte alls likt ursprunget ex om man ersätter alla ogiltiga tecken med ett underscore eller bindestreck.

Finns det någon bra funktion för att ex göra om å, ä, ö till a och o samt andra specialtecken till något likvärdigt och raderar mellanrum i filnamnet?

Med regex bör du ju kunna filtrera bort [^a-zA-Z0-9_].

Googla på "slugify javascript" - finns massor med kodexempel & bibliotek

/js

Räcker det inte med URL-encode?
https://www.php.net/manual/en/function.urlencode.php

Edit: Sorrry läste frågan slarvigt. Slugify låter bra, sök på det.

Finns det något som gör att du måste behålla det ursprungliga filnamnet?

Best practice är annars att döpa om filen efter uppladdning, dels för att undvika eventuella namnkonflikter, men även för att en illasinnad person inte ska kunna gissa sig till filnamn som denne inte har behörighet att visa (givet att du inte implementerat någon form av ACL).

Om de uppladdade filerna inte publiceras offentligt efter uppladdning blir det även svårare för en angripare att hitta och köra en potentiellt skadlig fil som denne laddat upp om filen har döpts om med ett nytt filnamn (som inte går att gissa).

Jag håller med att det är bättre av integritetsskäl och för att undvika namnkrock att ändra filnamnet till ett UID och spara det riktiga filnamnet i en databas som sedan används vid nedladdning. Men spelar filnamnet egentligen någon roll säkerhetsmässigt om man sparar uppladdade filer utanför den publika delen av servern?

Det finns givetvis flera sätt att lösa det på och det du precis föreslog är väll ett bra sätt det också förstås.

Jag vet dock inte om du menade att det skulle fungera så att filer utanför den publika delen skulle hämtas baserat på ett filnamn i urlen?
Typ enligt följande:

Om "namn_pa_fil.jpg" är ett namn/ID som används för att hämta en fil på en annan plats än den publika delen "uploads" (i detta exempel) måste man nog själv implementera något eget skydd mot path traversal, alternativt ha en "lookup table" (vilket det verkade som att du föreslog), så att det inte blir en direkt filreferens utanför den publika delen.

Annars kanske någon försöker göra någonting i stil med:

Om du döper om filnamnet till ett UID så borde du väll dock kunna spara filen på den publika delen med en direkt referens (givet att man inte ska ha någon ACL) utan att det, mig veterligen, borde bli någon större risk.

Jag har lärt mig att man bör undvika alla användargenerade filer i publika delen. Om det ligger utanför detta så är det omöjligt att hämta filen genom att lista ut någon URL. Jag pratar utifrån perspektivet Apache2 på Linux.

Ja, webbservern är normalt sandboxad, men skript som man själv skriver kan komma åt andra delar av filsystemet.

Jag insåg nu att mitt exempel nog var lite dumt då det bygger på en teknik där man i sin .htaccess (om man använder Apache) skickar alla request som inte har någon motsvarande fil eller mapp till index.php enligt följande:

Och att man efter det sedan hanterar de requesten i sin egen applikation.

Detta gör att om en användare t.ex. efterfrågar https://example.com/uploads/namn_pa_fil.jpg, och "/uploads/namn_pa_fil.jpg" inte existerar, så kan man själv bestämma hur man vill svara på det anropet, genom att t.ex. läsa "namn_pa_fil.jpg" från en helt annan plats.

Ett bättre exempel hade förmodligen varit:
https://example.com/gallery.php?image=namn_pa_fil.jpg

Min poäng var bara att webapplikationen kan bli sårbar för path traversal om man bestämmer sig för att göra en egen lösning för att läsa filer som ligger utanför den publika delen.

Om en uppladdad fil över huvud taget inte ska gå att komma åt av användare i efterhand så är det väll lämpligt att lägga den utanför den publika delen förstås.
Men ska t.ex. en uppladdad bild visas på hemsidan någonstans så kommer man i sådant fall att behöva göra ett eget skript för att läsa och presentera den filen, och där behöver man vara lite på sin vakt i så fall.