2013-01-25 10 views
6

Pytanie nie wynikają z tego:
Why does the browser modify the ID of an HTML element that contains &#x?Czy ten kod jest podatny na ataki XSS?

otrzymuje następujące strony:

<html> 
    <head> 
    <script type="text/javascript"> 
     // -------------------------------------------------------- 
     // could calling this method produce an XSS attack? 
     // -------------------------------------------------------- 
     function decodeEntity(text){ 
     text = text.replace(/<(.*?)>/g,''); // strip out all HTML tags, to prevent possible XSS 
     var div = document.createElement('div'); 
     div.innerHTML = text; 
     return div.textContent?div.textContent:div.innerText; 
     } 
     function echoValue(){ 
     var e = document.getElementById(decodeEntity("/path/&#x24;whatever")); 
     if(e) { 
      alert(e.innerHTML); 
     } 
     else { 
      alert("not found\n"); 
     } 
     } 
    </script> 
    </head> 
    <body> 
    <p id="/path/&#x24;whatever">The Value</p> 
    <button onclick="echoValue()">Tell me</button> 
    </body> 
</html> 

id elementu <p> zawiera znaki, które uciekły w celu zapobiegania atakom XSS. Część HTML i część JS są generowane przez serwer, a serwer wstawia tę samą wartość ewakuowaną (która może pochodzić z niezabezpieczonego źródła) na obu częściach.

Serwer ucieka następujące zakresy znaków w formacie &#x:

  • 0x00 – 0x2D
  • 0x3A – 0x40
  • 0x5B – 0x5e
  • 0x60
  • 0x7B – 0xFF
  • 0x0100 – 0xFFFF

Innymi słowy: tylko znaki, które są nie uciekł są:

  • 0x2E – 0x39 (., /, )
  • 0x41 – 0x5A (AZ)
  • 0x5F (_)
  • 0x61 – 0x7A (az)

Teraz muszę uzyskać dostęp do tej <p> poprzez javascript. Funkcja echoValue() w zadawanym pytaniu zawsze kończyła się niepowodzeniem, ponieważ przeglądarka konwertuje &#x24; na $ w części HTML, ale pozostawia je jako &#x24; w części JS.

Tak, Gareth wymyślił an answer, który jest prosty i działa.

Obawiam się, że możliwość ataku XSS, który został wyeliminowany przez ucieczkę z ciągów dynamicznych, pojawi się ponownie podczas korzystania z funkcji decodeEntity() podanej w odpowiedzi przywoływanej.

Czy ktoś może wskazać, czy może istnieć obawy związane z bezpieczeństwem (który?) lub nie (dlaczego nie?)?

+0

Po prostu nie zamykaj serwera wewnątrz skryptu. – Bergi

Odpowiedz

4

raz pierwszy proponuję rzucić okiem na poniższe linki omawianie HTML sanitarnych w JavaScript i XSS w javascript:

Bezpieczeństwa Lekcja nr 1: Nie wymyślaj ponownie koła. Jeśli coś zostało zrobione wcześniej, jest szansa, że ​​wykonali lepszą pracę niż rozwiązanie doraźne.

Mimo że nie mogę z góry wyobrazić sobie sposobu na wykorzystanie twojego prostego wyrażenia, nie jestem przekonany, że naprawdę przechwytuje wszystkie przypadki. Pierwsze łącze zapewnia rozwiązanie, które jest bardziej dopracowane i zostało dokładnie sprawdzone i przetestowane.

Proponuję również zapoznać się z XSS Filter Evasion Cheat Sheet. Pokazuje naprawdę dobrze, jakie nieprzyjemne rzeczy mogą wymyślić ludzie.

+2

Po prostu obserwacja ... oba linki prowadzą do tego samego adresu URL. Może to nie było celowe. –

0

dodatkowych ograniczeń przebywa zastosować na wejściu może spowodować atak się nie powiedzie, ale przy założeniu dowolnego wejścia do decodeEntity, oto przykład z systemem skryptu:

decodeEntity("<img onerror='alert(\"test\")'\nsrc='test'>") 

To działa, ponieważ /<(.*?)>/ pasuje tylko wtedy, gdy < i > są w tej samej linii.