Vad är sfgRmluamFuX1R5c[...]?
 

Får in en request då och då som verkar stoppa in strängen sfgRmluamFuX1R5c(etc) i sökvägen till en extern fil. Det är alltid samma fil. Totalt är det 72 tecken som läggs in och det är alltid mot slutet av sökvägen som det läggs in.

Vet nån vad det här är för något?

Inget Cache skydd?

Testa en base64_decode på strängen..

Nej, det sätts inga cache-headers för sidorna om det var det du menade. Filen som sökvägen pekar på har cache-headers dock.

Base64:

Ok...

Vad säger referer headern?

Referrer innehåller sidan som filen inkluderas på. Den inkluderade filen är ett Javascript.

Ser nu att det finns en header som kan indikera att användarn kommit in via en proxy av något slag.
Kollade upp IP-adressen också och den pekar på:

JS-filen som inkluderas är tyvärr viktig för att många av funktionerna ska fungera på ett bra sätt. När det läggs in skräptecken i sökvägen innebär det att filen inte hittas.

Finns det ingen här som har råkat ut för något liknande?

Gör som så att du hakar på ett utropstecken bakom .js

så kommer den inkluderas och inte cachas.

Du säger utropstecken (!) med skriver frågetecken (?), var är det som gäller? ;)

Frågetecknet gör att det blir en ny fil i cachen. Det skulle således inte göra någon skillnad.

Kanske har jag berättat för lite för att ni ska kunna hjälpa till. Jag försöker att berätta lite mer.

Jag har en html-sida.
Sidan innehåller sökvägar till externa filer varav en är ett javascript (som ska cachas).
Sökvägen till javascriptet modifieras av någon anledning vilket inte är önskvärt.

Om sökvägen ser ut såhär:
...ändras den till:
och då blir det fel. Visst skulle man kunna hantera felaktiga parametrar bättre på serversidan men det görs tydligen inte nu.

Frågan är varför dessa skräptecken infogas och vad man kan göra för att förhindra det. Jag ska kika lite närmare på vilka headers som skickas med i svaret när jag är tillbaks på jobbet på måndag. Kanske skickar vi felaktiga headers som gör att proxyn (om det nu är en proxy) pillar i innehållet. Det låter lite konstigt att den skulle göra så men vad vet jag?

Andra sökvägar ser ut på samma sätt men anropen till dessa förändras inte.

Base64-decodade strängen igen och fick ut ett resultat som sa lite mer än det förra. En sökning på Google leder till http://www.m86security.com/ och de verkar erbjuda säkerhetslösningar som ibland gör lite för mycket.

Tack för hjälpen!