Ja, browseren og webserveren er på samme maskine!

Når jeg prøver at integrere en HTML-fil uden for WWW-roden i en iframeog dermed bruge file:/// URL-syntaks, den ignoreres. Ingen fejlmeddelelse logget eller noget. Der gøres intet overhovedet.

Hvis jeg ændrer stien fra file:///C:\blablabla.html til ./blablabla.html, og læg filen i WWW-roden, den viser HTML-siden i iframe. Så det er ikke en form for grundlæggende problem med visning af iframes eller noget. Jeg har prøvet både med og uden URL-kodning af C:\... en del.

Er IFRAMEs i sagens natur ikke i stand til at vise file:/// URI'er, selvom MozDev-siden ikke nævner nogen som helst begrænsninger for src attribut? https://developer.mozilla.org/da-DK/docs/Web/HTML/Element/iframe

Jeg har lige pisket op en meget hurtig test og bekræfter, at jeg ikke har noget problem med at vise fil: /// URL'er i en iframe i enten Chrome eller Firefox.

Jeg bemærker, at jeg bruger Linux på mit skrivebord. Jeg formoder (men kan ikke let teste), at det i henhold til 1.2.3 i RFC3986 er din brug af et tilbageslagstegn - spec kræver, at delimeteret er "/", selvom jeg forventer, om tilbageslag virker muligvis browserimplementeringsspecifik. .

  • Nå, jeg prøvede lige nu med alle \ s omdannet til / s, men det samme sker: intet iframe-indhold og ingen fejl eller netværksfanehændelser logget. Pale Moon på Windows.
  • 2 Læs læsning af kb.mozillazine.org/… - en anden begrænsning - og en, du vil løbe ind i, er at de fleste browsere forhindrer dig i at medtage en lokal fil fra et eksternt websted, hvilket betyder at du ikke kan blande http: // eller https: // URL'er med fil: /// iframes i det mindste for Firefox-baserede browsere og sandsynligvis alle browsere. Da Pale Moon er en gaffel fra Firefox, der ville forklare det.

file: URL'er er problematiske set ud fra et sikkerhedsmæssigt synspunkt. Moderne browsere har tilføjet mange begrænsninger for file: URL'er. Det er ikke kun i iframes. file: URL'er er blokeret som kilde til

  • billeder
  • JavaScript
  • CSS
  • XHR (AJAX) opkald
  • iframes
  • rammesæt

Den grundlæggende sårbarhed er, at en angriber kan få fat i en følsom fil fra det lokale filsystem, når du besøger deres websted. Overvej følgende, som uden begrænsninger for iframe vil indlæse loginoplysninger for mange systemer:

<iframe src=file:///etc/passwd> 

Iframes er typisk sandkasser, så det overordnede websted ikke har fuld adgang til dem. Sandboksning er dog ikke idiotsikker, og hackere har fundet visse tilfælde, der giver dem mulighed for at komme rundt.

En anden sårbarhed er at tvinge brugeren af ​​et websted til at downloade en ondsindet fil (normalt HTML, PDF eller DOC) og derefter bruge en iframe med en file: URL til at udføre denne fil fra det lokale downloads-bibliotek. I ældre browsere, når det sker, kører den ondsindede fil med fuld adgang til det lokale filsystem.

For at bekæmpe disse problemer har moderne browsere:

  • Begrænsede live-websteder fra at bruge indlejring file: URL'er som beskrevet ovenfor
  • Begrænsede live-websteder, der endda linker til file: URL'er. Nu når du klikker på et link til en file: URL, der sker intet, og der vises en fejlmeddelelse i udviklerkonsollen.
  • Begrænset lokalt åbnet file: URL'er fra at få adgang til hele det lokale system. I nogle moderne browsere, lokale file: URL'er kan ikke engang køre JavaScript eller indlæse billeder, selv når disse ressourcer er i samme bibliotek.

Hvis du forsøger at udvikle et websted lokalt, giver de fleste browsere dig mulighed for at slå nogle af disse begrænsninger fra, så du kan få dit arbejde udført. Brug bare ikke din browser på live-sider med disse sikkerhedsbegrænsninger slået fra. For eksempel er der instruktioner til at gøre det i Firefox.

arbejdet for dig: Charles Robertson | Ønsker du at kontakte os?