Tego odcinka mogłoby właściwie nie być. W tym przypadku sytuacja jest praktycznie taka sama, jak w poprzednim przykładzie. Dobrze to widać poniżej:
<a href="#" onclick="javascript:doStuff('!\"#$%&\'()*+,-./:;<=>?@[\\]^_`{|}~')">demo 3</a><br /> <a href="#" onclick="javascript:doStuff('!\"#$%&\'()*+,-.\/:;<=>?@[\\]^_`{|}~')">demo 4</a><br />
Jedyna różnica pojawia się przy znaku /, który w drugim przypadku zyskuje postać \/. Czy ma to jakieś znaczenie w tym konkretnym kontekście? Może w pewnym, niewielkim stopniu ma, ale przed XSS nie chroni, przykład:
"><img src=x onerror=eval(String.fromCharCode(97,108,101,114,116,40,39,120,115,115,39,41))><foo bar="
Różnica w stosunku do poprzedniego przykładu sprowadza się do tego, że w tym przypadku nie jestem w stanie uzyskać tagu:
</script>
ponieważ funkcja escapowania znaków spowoduje jego przekształcenie do postaci:
<\/script>
Użycie String.fromCharCode natomiast obchodzi drobną niedogodność związaną z brakiem znaków ', " oraz / dostępnych w "czystej" postaci. Jak widać całkiem dobrze można sobie poradzić bez nich.
Pora na zakończenie tematu przykładu z niewłaściwym encodingiem (patrz: #1, #2, #3 i #4). Ponownie, by nie przeciągać, dla tradycyjnego zestawu znaków testowych otrzymujemy: doStuff('!\\"#$%&\'()
Przesłany: Dec 17, 15:15
Pokazanie przykładów niewłaściwego encodingu mamy za sobą (patrz: #1, #2, #3, #4 i #5). Na koniec przykład: http://bootcamp.threats.pl/lesson09b/, w którym encoding jest realizowany za pośrednictwem ESAPI (konkretnie owasp-esapi-php, jest to jeszcze wersj
Przesłany: Dec 18, 14:47