Jaki\u015b czas temu\u00a0rejestrowa\u0142em si\u0119 na\u00a0pewnej stronie internetowej. Podczas procesu rejestracji zauwa\u017cy\u0142em, \u017ce po wype\u0142nieniu formularza, w nast\u0119pnym kroku, wpisane przeze mnie dane wy\u015bwietlone s\u0105 w celu ich potwierdzenia. Dodatkowo mog\u0142em cofn\u0105\u0107 si\u0119 do formularza i poprawi\u0107 wprowadzane dane. Takie zachowanie, zwykle kusi mnie, aby sprawdzi\u0107, czy autor aplikacji prawid\u0142owo radzi sobie z ochron\u0105 przed atakiem typu XSS – Cross Site Scripting.<\/p>\n
W pierwszej kolejno\u015bci w cz\u0119\u015bci p\u00f3l wprowdzi\u0142em prosty test na wykorzystywanie kodowania HTML:<\/p>\n
'';!--\"<TEST>=&{()}<\/pre>\ni zatwierdzi\u0142em formularz. Wynik by\u0142 bardziej ni\u017c obiecuj\u0105cy.<\/p>\n
<p class=\"data\">'';!--\"<TEST>=&{()}<\/p><\/pre>\n\u017baden z wprowadzonych znak\u00f3w nie zosta\u0142 poddany kodowaniu HTML. Co wi\u0119cej, wprowadzony tag HTML nie zosta\u0142 usuni\u0119ty, co oznacza, \u017ce prawdopodobnie na danych wej\u015bciowych nie s\u0105 przeprowadzane \u017cadne testy na zawarto\u015b\u0107 kody HTML. Postanowi\u0142em wyedytowa\u0107 dane i wprowadzi\u0142em standardowy kod wy\u015bwietlaj\u0105cy okienko z pomoc\u0105 Java Script.<\/p>\n
<script>alert(1);<\/script><\/pre>\nPo przej\u015bciu na kolejn\u0105 stron\u0119 oczywi\u015bcie okienko si\u0119 pojawi\u0142o, co dowodzi istnieniu podatno\u015bci XSS. Co wi\u0119cej, analizuj\u0105c parametry kolejnych \u017c\u0105da\u0144, okaza\u0142o si\u0119, \u017ce warto\u015bci wprowadzane w formularzu rejestracyjnym zosta\u0142y ju\u017c zapisane w bazie danych przed wy\u015bwietleniem strony do potwierdzenia danych (tzw. „persistent XSS”). Stwarza to jeszcze wi\u0119ksze mo\u017cliwo\u015bci do nadu\u017cy\u0107, gdy\u017c zapisane dane mog\u0105 by\u0107 teraz wy\u015bwietlone na bardziej wra\u017cliwych stronach aplikacji, np. w panelu administratora<\/strong>.<\/p>\nSkoro XSS wyst\u0119powa\u0142 na stronie wy\u015bwietlaj\u0105cej moje dane, zastanowia\u0142em si\u0119 czy jestem w stanie jeszcze bardziej poszerzy\u0107 wektor mojego „ataku”. Okaza\u0142o si\u0119, \u017ce gdy wracam do formularza rejestracyjnego w celu poprawy wprowadzonych danych kod p\u00f3l formularza wygl\u0105da tak:<\/p>\n
<input class=\"form-control\" type=\"text\" name=\"data\" value=\"<script>alert(1);<\/script>\" maxlength=\"35\"\/><\/pre>\nPowstaje pytanie, czy da si\u0119 tak zmodyfikowa\u0107 kod skryptu aby, dzia\u0142a\u0142 w obu przypadkach (kontekstach)? Spr\u00f3bujmy…
\nWida\u0107, \u017ce wprowadzona warto\u015b\u0107 nie wykona si\u0119, gdy\u017c znajduje si\u0119 tym razem wewn\u0105trz warto\u015bci atrybutu „value” tagu „input”. Aby zadzia\u0142 musimy nasz atak musi wykona\u0107 kilka czynno\u015bci:<\/p>\n
\n- zamkn\u0105\u0107 atrybut cudzys\u0142owem podw\u00f3jnym „””,<\/li>\n
- zamkn\u0105\u0107 tag „input”,<\/li>\n
- wprowadzi\u0107 skrypt,<\/li>\n
- wykomentowa\u0107 parametr „maxlength”<\/li>\n<\/ol>\n
Zobaczmy jak mo\u017ce wygl\u0105da\u0107 taki atak:<\/p>\n
\"\/><script>alert(1);<\/script><!--<\/pre>\n , a wynikowy kod HTML wygl\u0105a\u0107 b\u0119dzie wtedy tak:<\/p>\n
<input class=\"form-control\" type=\"text\" name=\"data\" value=\"\"\/><script>alert(1);<\/script><!--\" maxlength=\"35\"\/><\/pre>\nOczywi\u015bcie jest to tylko jedna z mo\u017cliwo\u015bci jak\u0105 mo\u017cemy wykorzysta\u0107.<\/p>\n","protected":false},"excerpt":{"rendered":"
Jaki\u015b czas temu\u00a0rejestrowa\u0142em si\u0119 na\u00a0pewnej stronie internetowej. Podczas procesu rejestracji zauwa\u017cy\u0142em, \u017ce po wype\u0142nieniu formularza, w nast\u0119pnym kroku, wpisane przeze mnie dane wy\u015bwietlone s\u0105 w celu ich potwierdzenia. Dodatkowo mog\u0142em cofn\u0105\u0107 si\u0119 do formularza i poprawi\u0107 wprowadzane dane. Takie zachowanie, zwykle kusi mnie, aby sprawdzi\u0107, czy autor aplikacji prawid\u0142owo radzi sobie z ochron\u0105 przed atakiem\u2026 Read More »<\/a><\/span><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[11],"tags":[26],"class_list":["post-203","post","type-post","status-publish","format-standard","hentry","category-security","tag-miroburn_challenge"],"_links":{"self":[{"href":"https:\/\/brozanski.net\/index.php\/wp-json\/wp\/v2\/posts\/203","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/brozanski.net\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/brozanski.net\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/brozanski.net\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/brozanski.net\/index.php\/wp-json\/wp\/v2\/comments?post=203"}],"version-history":[{"count":19,"href":"https:\/\/brozanski.net\/index.php\/wp-json\/wp\/v2\/posts\/203\/revisions"}],"predecessor-version":[{"id":222,"href":"https:\/\/brozanski.net\/index.php\/wp-json\/wp\/v2\/posts\/203\/revisions\/222"}],"wp:attachment":[{"href":"https:\/\/brozanski.net\/index.php\/wp-json\/wp\/v2\/media?parent=203"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/brozanski.net\/index.php\/wp-json\/wp\/v2\/categories?post=203"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/brozanski.net\/index.php\/wp-json\/wp\/v2\/tags?post=203"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}