Informasjonsteknologi, internett, webprogrammering, IT, Hi-Tech,…. XML-elementer. Tomme og ikke-tomme XML-elementer

Legg igjen en kommentar 6,950

Oversettelse
Opplæringen

SQL-injeksjon, forfalskning av forespørsler på tvers av nettsteder, ødelagt XML ... Skremmende, skumle ting som vi alle ønsker å beskytte oss mot, men vi trenger bare å vite hvorfor dette skjer. Denne artikkelen forklarer det grunnleggende konseptet bak det hele: strenger og streng-i-streng-håndtering.

Hovedproblem

Dette er bare tekst. Ja, bare tekst er hovedproblemet. Nesten alt i et datasystem er representert av tekst (som igjen er representert av byte). Bortsett fra at noen tekster er beregnet på datamaskinen, mens andre er for mennesker. Men både de, og de, forblir fortsatt teksten. For å forstå hva jeg snakker om, skal jeg gi deg et lite eksempel:

Homo sapiens Anta at det er den engelske teksten, som jeg ikke vil oversette til russisk

Tro det eller ei: dette er tekst. Noen kaller det XML, men det er bare tekst. Det er kanskje ikke egnet for å vise til en engelsklærer, men det er fortsatt bare tekst. Du kan skrive det ut på en plakat og gå på stevner med det, du kan skrive det i et brev til moren din ... dette er tekst.

Vi ønsker imidlertid at visse deler av denne teksten skal ha en viss betydning for datamaskinen vår. Vi ønsker at datamaskinen skal kunne trekke ut forfatteren av teksten og selve teksten hver for seg slik at vi kan gjøre noe med den. Konverter for eksempel ovenstående til dette:
Anta at det er den engelske teksten, som jeg ikke vil oversette til russisk av Homo Sapiens
Hvordan vet datamaskinen hvordan man gjør dette? Vel, fordi vi veldig praktisk har pakket inn visse deler av teksten med spesielle ord i morsomme parenteser som og. Siden vi har gjort dette, kan vi skrive et program som søker etter disse spesifikke delene, trekke ut teksten og bruke den til en egen oppfinnelse.

Med andre ord, vi brukte visse regler i teksten vår for å betegne en spesiell betydning som noen, som følger de samme reglene, kan bruke.
Ok, dette er ikke så vanskelig å forstå. Men hva om vi vil bruke disse morsomme parentesene, som har en spesiell betydning, i teksten vår, men uten å bruke akkurat denne betydningen? .. Som dette:

Homo sapiens < n and y >

Symboler "<" и ">"er ikke noe spesielt. De kan lovlig brukes hvor som helst, i hvilken som helst tekst, som i eksempelet ovenfor. Men hva med ideen vår om spesielle ord, som? Betyr det at det også er et slags nøkkelord? I XML, det er mulig Ja, eller kanskje ikke Dette er tvetydig Siden datamaskiner ikke er så flinke til å håndtere uklarheter, kan noe til slutt gi et uventet resultat hvis vi ikke prikker i-ene og tvetydig.
Du kan løse dette dilemmaet ved å erstatte tvetydige symboler med noe entydig.

Homo sapiens Grunnleggende matematikk forteller oss at hvis x< n and y >n, x kan ikke være større enn y.

Nå skal teksten være helt entydig. "<" равносильно "<", а ">" - ">".
Den tekniske definisjonen av dette er - skjerming , unngår vi spesialtegn når vi ikke vil at de skal ha sin egen spesielle betydning.
unnslippe | iˈskāp | [ingen obj. ] slå seg løs [med obj. ] legger ikke merke til / husker ikke [...] [med obj. ] IT: grunn til å bli tolket annerledes [...]
Hvis enkelte tegn eller sekvenser av tegn i teksten har spesiell betydning, bør det være regler for hvordan man skal løse situasjoner der disse tegnene skal brukes uten å påberope seg deres spesielle betydning. Eller, med andre ord, å unnslippe svarer på spørsmålet: "Hvis disse karakterene er så spesielle, hvordan kan jeg bruke dem i teksten min?".
Som du kan se i eksemplet ovenfor, er og-tegnet (&) også et spesialtegn. Men hva om vi vil skrive "<", но без интерпретации этого как "<"? В XML, escape-последовательность для &, это - " & ", т.е. мы должны написать: " &< "

Flere eksempler

XML er ikke det eneste tilfellet av spesialtegn "lider". Enhver kildekode, i et hvilket som helst programmeringsspråk, kan demonstrere dette:
var name = "Homo Sapiens"; var contents = "Anta at det er den engelske teksten, som jeg ikke vil oversette til russisk ";
Det er enkelt – vanlig tekst er tydelig atskilt fra «ikke-tekst» med doble anførselstegn. På samme måte kan du bruke teksten min fra kurset i matematisk analyse:
var name = "Homo Sapiens"; var contents = "Grunnleggende matematikk forteller oss at hvis x< n and y >n, x kan ikke være større enn y. ";
Kul! Og du trenger ikke engang ty til screening! Men vent, hva om jeg vil sitere noen?
var name = "Homo Sapiens"; var contents = "Platon sies å ha sagt" Lorem ipsum dolor sit amet ".";
Hmm ... tristhet, lengsel. Som menneske kan du bestemme hvor teksten begynner og slutter og hvor sitatet er. Imidlertid ble dette igjen tvetydig for enhver datamaskin. Vi må komme opp med noen unnslippende regler som vil hjelpe oss å skille mellom det bokstavelige "og", som betyr slutten på teksten. De fleste programmeringsspråk bruker skråstreken:
var name = "Homo Sapiens"; var contents = "Platon sies en gang å ha sagt \" Lorem ipsum dolor sit amet \ ".";
"\" gjør tegnet etter det ikke-spesielt. Men dette betyr igjen at "\" er et spesialtegn. For entydig å skrive dette tegnet i teksten, legg til det samme tegnet ved å skrive: "\\". Morsomt, ikke sant?

Angrip!

Det ville ikke vært så ille om du bare måtte ty til å rømme. Det er selvfølgelig anspent, men det er ikke så ille. Problemer begynner når noen programmer skriver tekst til andre programmer slik at de kan "lese" den. Og nei, dette er ikke science fiction, det skjer hele tiden. For eksempel, på dette nettstedet, når du publiserer en melding, skriver du den ikke manuelt i HTML-format, men skriver bare tekst, som som et resultat blir konvertert av dette nettstedet til HTML, hvoretter nettleseren allerede konverterer den "genererte" HTML-en igjen til lesbar tekst.

Et annet vanlig eksempel og kilde til mange sikkerhetsproblemer er SQL-spørringer. SQL er et språk utviklet for å forenkle kommunikasjon med databaser:
Det er praktisk talt ingen spesialtegn i denne teksten, for det meste engelske ord. Likevel har praktisk talt hvert ord i SQL en spesifikk betydning. Dette brukes i mange programmeringsspråk rundt om i verden i en eller annen form, for eksempel:
$ query = "VELG telefonnummer FRA brukere WHERE name =" Alex ""; $ resultat = mysql_query ($ query);
Disse to enkle linjene tar bort fra oss den forferdelig komplekse oppgaven med å be om et program fra en database som tilfredsstiller kravene våre. Databasen "siler" kanskje terabyte med biter og byte for å returnere et pent formatert resultat til programmet som sender forespørselen. Seriøst, all denne dritten er innkapslet i en enkel anglo-lignende setning.

For å gjøre dette nyttig, er spørsmål som dette ikke hardkodet, men basert på brukerinndata. Dette er det samme forslaget rettet mot forskjellige brukere:
$ navn = $ _POST ["navn"]; $ query = "VELG telefonnummer FRA brukere WHERE name =" $ navn ""; $ resultat = mysql_query ($ query);
I tilfelle du bare leser denne artikkelen: Dette er et antieksempel! Dette er det verste du noen gang kan gjøre! Dette er et sikkerhetsmareritt! Hver gang du skriver noe slikt, vil en uskyldig kattunge dø! Cthulhu vil sluke sjelen din for dette!

La oss nå se hva som skjer her. $ _POST ["navn"] er en verdi som en tilfeldig bruker skrev inn i en tilfeldig form på din tilfeldige nettside. Programmet ditt vil bygge en SQL-spørring ved å bruke denne verdien som brukernavnet du vil finne i databasen. Denne SQL "erklæringen" sendes deretter rett til databasen.

Det høres ikke så ille ut, gjør det? La oss prøve å legge inn noen tilfeldige verdier som du kan legge inn på din tilfeldige nettside, og hvilke søk som kommer ut av dette:

Alex
SELECT phone_number FROM brukere WHERE name = "Alex"
Mc "Donalds
SELECT phone_number FRA brukere WHERE name = "Mc" Donalds "
Joe "; DROP TABLE-brukere; -
SELECT phone_number FROM brukere WHERE name = "Joe"; DROP TABLE brukere; -"
Den første forespørselen ser ikke skummel ut, men ganske søt, ikke sant? Nummer 2 ser ut til å "noe" skade syntaksen vår på grunn av tvetydighet. "Forbannet tysk! Nummer 4 er litt dumt. Hvem ville skrive det? Det gir ikke mening ...
Men ikke for databasen som behandler forespørselen ... Databasen har ingen anelse om hvor denne forespørselen kom fra, og hva den skal bety. Det eneste hun ser er to spørsmål: finn nummeret til brukeren som heter Joe, og slipp deretter brukertabellen (etterfulgt av kommentaren "), og dette vil bli gjort vellykket.

Dette burde ikke være nyheter for deg. I så fall, les denne artikkelen igjen, for du er enten ny på programmering eller har bodd i en hule de siste 10 årene. Dette eksemplet illustrerer det grunnleggende om SQL-injeksjon som brukes over hele verden. for å slette data, eller få data som ikke akkurat skal mottas, eller komme inn i systemet uten å ha rettigheter til det osv. Og alt fordi DB tar den engelsklignende "setningen" for bokstavelig.

Gooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo

Neste trinn: XSS-angrep. De fungerer på samme måte, bare de gjelder for HTML.
La oss si at du har løst problemene med databasen, få data fra brukeren, skrive dem til databasen og sende dem tilbake til nettsiden for brukere å få tilgang til. Dette er hva et typisk forum, kommentarsystem osv. gjør. Et sted på nettstedet ditt er det noe som dette:

Postet avpå

Hvis brukerne dine er hyggelige og snille, vil de legge ut sitater fra gamle filosofer, og meldinger vil se omtrent slik ut:

Skrevet av Platon 2. januar, 15:31

Jeg skal ha sagt "Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercising ullamco laboris nisi ut aliquipo ex ea quat."

Hvis brukere er smarte, vil de sannsynligvis snakke om matematikk, og meldingene vil være slik:

Skrevet av Pascal 23. november, 04:12

Grunnleggende matematikk forteller oss at hvis x< n and y >n, x kan ikke være større enn y.

Hmm ... Igjen disse vanærerne av parentesene våre. Vel, fra et teknisk synspunkt kan de være tvetydige, men nettleseren vil tilgi oss for det, ikke sant?

OK, STOPP, hva i helvete? Har noen joker introdusert javascript-koder til forumet ditt? Alle som ser på dette innlegget på nettstedet ditt, laster nå ned og kjører skript i sammenheng med nettstedet ditt som kanskje ikke gjør noe. Og dette er ikke bra.

Bør ikke tas bokstavelig

I de nevnte tilfellene ønsker vi på en eller annen måte å informere vår database eller nettleser om at dette bare er tekst, ikke gjør noe med det! Med andre ord, vi ønsker å "fjerne" den spesielle betydningen av alle spesialtegn og nøkkelord fra all informasjon gitt av brukeren, fordi vi ikke stoler på ham. Hva å gjøre?

Hva? Hva sier du, gutt? Å, du sier "skjerming"? Og du har helt rett, ta en kake!
Hvis vi bruker escape på brukerdataene før vi kombinerer dem med spørringen, er problemet løst. For databasespørsmålene våre vil det være noe sånt som:
$ navn = $ _POST ["navn"]; $ navn = mysql_real_escape_string ($ navn); $ query = "VELG telefonnummer FRA brukere WHERE name =" $ navn ""; $ resultat = mysql_query ($ query);
Bare én kodelinje, men nå kan ingen andre "hacke" databasen vår. La oss se hvordan SQL-spørringene vil se ut igjen, avhengig av brukerinndata:
Alex
SELECT phone_number FROM brukere WHERE name = "Alex"
Mc "Donalds
SELECT phone_number FRA brukere WHERE name = "Mc \" Donalds "
Joe "; DROP TABLE-brukere; -
SELECT phone_number FROM brukere WHERE name = "Joe \"; DROP TABLE brukere; -"
mysql_real_escape_string vil tilfeldig plassere en skråstrek foran alt som kan ha en spesiell betydning.

Vi bruker htmlspecialchars-funksjonen på alle brukerdata før vi viser dem. Nå ser skadedyrets melding slik ut:

Skrevet av JackTR 18. juli, 12:56

Merk at verdiene som mottas fra brukerne faktisk ikke er "ødelagt". Enhver nettleser analyserer dette som HTML og viser alt i riktig form.

Som bringer oss tilbake til...

Alt det ovennevnte viser et problem som er felles for mange systemer: tekst i tekst må escapes hvis den ikke skal ha noen spesialtegn. Når du plasserer tekstverdier i SQL, må de escapes i henhold til SQL-reglene. Når du plasserer tekstverdier i HTML, må de escapes i henhold til HTML-regler. Ved plassering av tekstverdier i (teknologinavn), må de escapes i henhold til reglene for (teknologinavn). Det er alt.

For å fullføre bildet

Det er selvfølgelig andre måter å håndtere brukerinndata på som bør eller ikke bør inneholde spesialtegn:

Validering
Du kan sjekke om brukerinndataene oppfyller en gitt spesifikasjon. Dersom du krever at et nummer legges inn, og brukeren legger inn noe annet, må programmet informere vedkommende om dette og avbryte inntastingen. Hvis alt dette er riktig organisert, er det ingen risiko for å gripe "DROP TABLE-brukere" der brukeren skulle skrive inn "42". Det er ikke veldig praktisk å unngå HTML / SQL-injeksjon fordi ofte er det påkrevd å godta fri-form tekst, som kan inneholde "cleats". Validering brukes vanligvis i tillegg til andre tiltak.
Sanering
Du kan også "stille" fjerne alle karakterer du anser som farlige. Fjern for eksempel alt som ser ut som en HTML-tag for å unngå å bli lagt til forumet ditt. Problemet er at du kan slette legitime deler av teksten.
Forberedte SQL-setninger
Det er spesielle funksjoner som gjør det vi ønsket: få databasen til å forstå forskjellene mellom selve SQL-spørringen og informasjonen brukerne gir. I PHP ser de omtrent slik ut:
$ stmt = $ pdo-> forberede ("VELG telefonnummer FRA brukere HVOR navn =?"); $ stmt-> kjør ($ _ POST ["navn"]);
Samtidig skjer sending i to trinn, og skiller tydelig mellom forespørselen og variablene. Databasen har muligheten til først å forstå strukturen til forespørselen, og deretter fylle den med verdier.

Hei, kjære besøkende på nettstedet! Fortsetter på XML-markeringsspråket, la oss se på bruken av attributter. Attributter kan være til stede i XML-elementer akkurat som i HTML. Attributter gir tilleggsinformasjon om et element.

XML-attributter

I HTML gir attributter tilleggsinformasjon om elementer:

XML-attributter må angis i anførselstegn

Verdiene attributter i xml skal alltid siteres. Både enkle og doble anførselstegn kan brukes. For å indikere kjønnet til et element, kan en person (person) skrives slik:

Hvis selve attributtverdien inneholder doble anførselstegn, kan du bruke enkle anførselstegn, som i dette eksemplet:

XML-elementer vs. attributter

Ta en titt på følgende eksempler:

Victoria
Petrova

hunn
Victoria
Petrova

I det første eksemplet er sex en egenskap. I sistnevnte er sex et element. Begge eksemplene gir samme informasjon.

Det er ingen regler for når du skal bruke attributter og når du skal bruke elementer. Attributter er nyttige i HTML. I XML anbefaler jeg deg å unngå dem. Bruk elementer i stedet.

Min favoritt måte

Følgende tre XML-dokumenter inneholder nøyaktig samme informasjon:

XML-datoattributtet brukes i det første eksemplet:

Det utvidede datoelementet brukes i det tredje: (DETTE ER MIN FAVORITTMÅTE):

10
01
2008

Peter
Sveta
Påminnelse

Unngå XML-attributter?

Noen av problemene med å bruke xml-attributter:

attributter kan ikke inneholde flere verdier (elementer kan)
attributter kan ikke inneholde trestrukturer (elementer kan)
attributter er vanskeligere å utvide (for fremtidige endringer)

Ikke gjør det på denne måten:

til = "Vasya" fra = "Sveta" overskrift = "Påminnelse"
body = "Ikke glem å ringe meg i morgen!"

XML-attributter for metadata

Vasya
Sveta
Påminnelse
Ikke glem å ringe meg i morgen!

Sveta
Vasya
Re: Påminnelse
OK

ID-attributtene ovenfor brukes til å identifisere forskjellige notater. De er ikke en del av notatet i seg selv.

Det jeg prøver å si her er at metadata (data om data) skal lagres som xml-attributter, og selve dataene skal lagres som elementer.

Takk for oppmerksomheten!.

I lang tid foreskriver standarden å bruke konstruksjonen "For innvendige tagger, anførselstegn" "brukes for å betegne attributter for å sette inn normale anførselstegn i HTML-tekst.

Imidlertid har jeg ennå ikke kommet over en nettleser som ikke vil vise som et anførselstegn et enkelt tegn "UTENFOR eventuelle tagger. Så fortell meg, kjære kolleger, kanskje det å bruke" utenfor tagger rett og slett er en kjedelig ting som ingen trenger? Er det mulig å skrive rolig og uten videre?Særlig i tekster hvor det er mye anførselstegn, og overholdelse av strenge designregler (om riktig bruk av nasjonale anførselstegn) er irrelevant.

IMHO, mange mennesker gjør dette ... men spørsmålet er ikke helt klart: hvis du forstår at du etter standarder må skrive anførselstegn som ", men lat, mens en haug med nettsteder fungerer slik, hva forventer du da høre om visning av anførselstegn vil bli støttet i nye versjoner av nettlesere, er det ingen som vet, så den mest åpenbare anbefalingen kan gis: hvis du ikke vil ha problemer i fremtiden 100 %, hold deg til standardene :) Men du vet det allerede. Eller venter du på bekreftelse: ja kjedelig det er alt, glem det, og om 10 år vil alt være det samme, garanterer jeg (Microsoft, Mozilla, etc.)?

Lynn "Coffeeman" [dossier]
ja, forresten ... nå er det nyttig å lese, ingen steder står det at sitater skal representeres i formen "
http://www2.stack.ru/~julia/HTML401/charset.html:

Noen forfattere bruker tegnenhetsreferansen "" "for å kode forekomster av doble anførselstegn ("), siden dette tegnet kan brukes til å skille attributtverdier.

om hva, nødvendigå bruke nøyaktig enhet sies det bare om<, >og &:

Hvis forfatteren ønsker å sette karakteren "<", во избежание возможной путаницы с началом тега (метка начала тега) он должен использовать ссылку "<" (десятичный код ASCII 60). Точно так же во избежание проблем со старыми версиями пользовательских агентов, некорректно принимающих символы ">"etter slutten av taggen (slutten av taggen), bruk linken"> "(desimal ASCII-kode 62).

For å unngå forvirring med tegnreferanser (startmerke for tegnreferanse), bruk "&" (ASCII desimalkode 38) i stedet for "&". I tillegg bør "&"-referansen også brukes i attributtverdier, siden tegnreferanser innenfor CDATA-attributtverdier er tillatt.

Men jeg forventer bare noe som Lynns svar: at det faktisk ikke finnes noen slik standard. Det gikk ikke engang opp for meg - informasjonen min er fra populære lærebøker og av grunner "alle gjør det".

Eller et annet alternativ: men hvis du følger de nye standardene som jeg ikke har møtt i min praksis - som xhtml (det virker som om jeg sjekket xhtml), så vil ikke dette trikset fungere. Derfor er det ikke nødvendig å skape problemer med portabiliteten til den skrevne HTML-koden.

Vel, eller til slutt: hvordan har du det selv?

& stiller forresten et lignende spørsmål. Dokumentet ovenfor sier "for å unngå forvirring". Men forvirring er bare mulig hvis & etterfølges av en av kodene. Hva om det for eksempel er en URL som ".... / script? A = 1 & B = 2"? Risikerer jeg noe hvis jeg feilaktig spesifiserer en slik URL som href (som selvfølgelig fungerer korrekt under testen)? Alt annet enn den ekstremt usannsynlige situasjonen at om 10 år (når siden er utdatert eller allerede har blitt omskrevet ti ganger) vil en enhet dukke opp med et ekstravagant navn & B uten slutten; ? Med andre ord, hvor nøye bør alle slike saker kontrolleres?

Daniel, hvis du er sikker på at du ikke har noen problemer med de eksisterende kodene, kan du skrive bare &. Hvis det i fremtiden dukker opp en ny kode, så tror jeg at den tydeligvis ikke er i HTML 4.01-spesifikasjonen, derfor bør den ikke påvirke et normalt erklært dokument. Eller håper du å sikre din støtte for fremtidige standarder ved å endre dokumentskjemaet?

Daniel Aliyevsky [dossier]
I XML byr heller ikke det vanlige anførselstegnet som tekst på noe problem (og dermed i XHTML, selvfølgelig). IMHO-sitater blir vanligvis oversatt til "bare av én grunn - jeg vil ikke skrive to funksjoner for å gjøre teksten trygg når den erstattes i XML / HTML / XHTML.

Som i HTML, XML-elementer kan ha attributter. I dette tilfellet, verdien attributter i XML og regelen for å lage dem er mye som.

Attributter gir tilleggsinformasjon om et element.

XML-attributter

I HTML gir attributter litt tilleggsinformasjon om et element:

Attributter gir ofte informasjon som ikke er en del av dataene. I eksemplet nedenfor er filtypen uavhengig av dataene, men denne informasjonen kan være viktig for applikasjoner som vil manipulere dette elementet:

datamaskin.gif

XML-attributter må angis

Attributtverdien må alltid stå i anførselstegn. Det kan være enten doble eller enkle anførselstegn. For eksempel kan en karakters kjønn skrives slik:

eller slik:

Hvis selve attributtverdien inneholder doble anførselstegn, kan enkle anførselstegn brukes. For eksempel:

eller bruk enhetssymboler:

XML-elementer eller attributter

Ta en titt på følgende eksempler:

Eksempel #1

Anna Smith

Eksempel nr. 2

hunn Anna Smith

I det første eksemplet er kjønn spesifisert i attributtet. I den andre registreres kjønn som et element. Begge eksemplene gir samme informasjon.

Det er ingen regler for når attributter skal brukes og når elementer skal brukes. Attributter er mye brukt i HTML. I XML er det etter min mening bedre å unngå dem og bruke elementer i stedet.

Hva er bedre?

Følgende tre XML-dokumenter inneholder nøyaktig samme informasjon:

Dato registrert som et attributt:

Tove Jani Påminnelse

Dato registrert som vare:

10/01/2008 Tove Jani Påminnelse Ikke glem meg denne helgen!

Dato registrert som utvidet element(Det beste alternativet etter min mening):

10 01 2008 Tove Jani Påminnelse Ikke glem meg denne helgen!

Unngå XML-attributter?

Det er noen problemer når du bruker attributter:

attributter kan ikke inneholde flere verdier (elementer kan)
attributter kan ikke inneholde trestrukturer (elementer kan)
attributter er vanskelige å utvide (for fremtidige endringer)

Bruk aldri følgende konstruksjoner:

XML-attributter for metadata

Noen ganger blir elementer tildelt identifikatorer. Disse identifikatorene brukes til å identifisere XML-elementer på nøyaktig samme måte som identifikasjonsattributter i HTML. Følgende eksempel viser dette:

Tove Jani Påminnelse Ikke glem meg denne helgen!

Jani Tove Re: Påminnelse jeg kommer ikke til å glemme

I eksemplet som vises, brukes id-attributtet til å identifisere forskjellige notater. Denne informasjonen er ikke en del av selve notatet.

Hovedideen med alt som er sagt er at metadata (data om data) skal registreres som attributter, og selve dataene som elementer.