<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Komentarze do: XSS-hackme: zwycięzca i rozwiązania</title>
	<atom:link href="http://lukasz.pilorz.net/2007/04/01/xss-hackme-zwyciezca-i-rozwiazania/feed/" rel="self" type="application/rss+xml" />
	<link>http://lukasz.pilorz.net/2007/04/01/xss-hackme-zwyciezca-i-rozwiazania/</link>
	<description>Bezpieczeństwo aplikacji internetowych</description>
	<lastBuildDate>Thu, 04 Jun 2009 21:19:31 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0</generator>
	<item>
		<title>Autor: jasio</title>
		<link>http://lukasz.pilorz.net/2007/04/01/xss-hackme-zwyciezca-i-rozwiazania/comment-page-1/#comment-143</link>
		<dc:creator>jasio</dc:creator>
		<pubDate>Fri, 06 Apr 2007 14:36:20 +0000</pubDate>
		<guid isPermaLink="false">http://lukasz.pilorz.net/index.php/2007/04/01/xss-hackme-zwyciezca-i-rozwiazania/#comment-143</guid>
		<description>No wszystko  jest jasne, oprocz jednego :)
W taki wypadku po co w ogole w utf-8 jest mozliwosc zapisu czegokolwiek w 6 formatach skoro nikt tego nie uzyje?</description>
		<content:encoded><![CDATA[<p>No wszystko  jest jasne, oprocz jednego :)<br />
W taki wypadku po co w ogole w utf-8 jest mozliwosc zapisu czegokolwiek w 6 formatach skoro nikt tego nie uzyje?</p>
]]></content:encoded>
	</item>
	<item>
		<title>Autor: Łukasz Pilorz</title>
		<link>http://lukasz.pilorz.net/2007/04/01/xss-hackme-zwyciezca-i-rozwiazania/comment-page-1/#comment-137</link>
		<dc:creator>Łukasz Pilorz</dc:creator>
		<pubDate>Thu, 05 Apr 2007 17:28:53 +0000</pubDate>
		<guid isPermaLink="false">http://lukasz.pilorz.net/index.php/2007/04/01/xss-hackme-zwyciezca-i-rozwiazania/#comment-137</guid>
		<description>Zachowanie Firefoksa, Opery, IE7 itd. jest poprawne. 0xC1 to początek dwubajtowej sekwencji UTF-8, ale kolejny bajt musi się w takiej sekwencji zaczynać od bitu 1, czyli mieć wartość przynajmniej 0x80. Bajty 0x01-0xBF mogą występować tylko w jednobajtowych znakach, dzięki czemu znaki UTF-8 z tego zakresu są jednocześnie poprawnymi znakami ASCII.

Teoretycznie 0x22 można zapisać też jako 0xC0 0xA2, ale dodatkowa zasada mówi o tym, że każdy znak musi być zapisany na minimalnej ilości bajtów, na której jest to możliwe. Nie powinno się interpretować nadmiarowych sekwencji - prowadziłoby to do niezliczonej ilości luk. Znaleziono wiele bardzo grożnych błędów w oprogramowaniu nie stosującym tej zasady - najbardziej znana jest chyba poniższa:
http://www.securityfocus.com/bid/1806/exploit

W związku z tą dodatkową zasadą, żadna poprawna sekwencja UTF-8 nie zaczyna się od bajtu 0xC0.</description>
		<content:encoded><![CDATA[<p>Zachowanie Firefoksa, Opery, IE7 itd. jest poprawne. 0xC1 to początek dwubajtowej sekwencji UTF-8, ale kolejny bajt musi się w takiej sekwencji zaczynać od bitu 1, czyli mieć wartość przynajmniej 0&#215;80. Bajty 0&#215;01-0xBF mogą występować tylko w jednobajtowych znakach, dzięki czemu znaki UTF-8 z tego zakresu są jednocześnie poprawnymi znakami ASCII.</p>
<p>Teoretycznie 0&#215;22 można zapisać też jako 0xC0 0xA2, ale dodatkowa zasada mówi o tym, że każdy znak musi być zapisany na minimalnej ilości bajtów, na której jest to możliwe. Nie powinno się interpretować nadmiarowych sekwencji &#8211; prowadziłoby to do niezliczonej ilości luk. Znaleziono wiele bardzo grożnych błędów w oprogramowaniu nie stosującym tej zasady &#8211; najbardziej znana jest chyba poniższa:<br />
<a href="http://www.securityfocus.com/bid/1806/exploit" rel="nofollow">http://www.securityfocus.com/bid/1806/exploit</a></p>
<p>W związku z tą dodatkową zasadą, żadna poprawna sekwencja UTF-8 nie zaczyna się od bajtu 0xC0.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Autor: jasio</title>
		<link>http://lukasz.pilorz.net/2007/04/01/xss-hackme-zwyciezca-i-rozwiazania/comment-page-1/#comment-134</link>
		<dc:creator>jasio</dc:creator>
		<pubDate>Thu, 05 Apr 2007 15:33:47 +0000</pubDate>
		<guid isPermaLink="false">http://lukasz.pilorz.net/index.php/2007/04/01/xss-hackme-zwyciezca-i-rozwiazania/#comment-134</guid>
		<description>W ogóle to ja nie wiem, czy programiście IE popełnili błąd, czy programiści FF? W końcu 0xc0,0x22, to jest jakiś znak utf-8. Dlaczego Firefox tego nie przetwarza? Dlaczego przeglądarki nie obsługują wszystkich 6 postaci każdego znaku w UTF-8?</description>
		<content:encoded><![CDATA[<p>W ogóle to ja nie wiem, czy programiście IE popełnili błąd, czy programiści FF? W końcu 0xc0,0&#215;22, to jest jakiś znak utf-8. Dlaczego Firefox tego nie przetwarza? Dlaczego przeglądarki nie obsługują wszystkich 6 postaci każdego znaku w UTF-8?</p>
]]></content:encoded>
	</item>
	<item>
		<title>Autor: Łukasz Pilorz</title>
		<link>http://lukasz.pilorz.net/2007/04/01/xss-hackme-zwyciezca-i-rozwiazania/comment-page-1/#comment-129</link>
		<dc:creator>Łukasz Pilorz</dc:creator>
		<pubDate>Wed, 04 Apr 2007 20:48:00 +0000</pubDate>
		<guid isPermaLink="false">http://lukasz.pilorz.net/index.php/2007/04/01/xss-hackme-zwyciezca-i-rozwiazania/#comment-129</guid>
		<description>Funkcja preg_match() potraktuje bajt zerowy w przeszukiwanym ciągu jak normalny znak, więc jest pod tym względem znacznie bezpieczniejsza. Nie można przy pomocy bajtu zerowego obejść filtrów bazujących na perlowych wyrażeniach regularnych.

Gdyby bajt zerowy trafił jakoś do wzorca, zostałby jednak potraktowany jako koniec tego wzorca. Nie wiem, dlaczego funkcja preg_quote() jest bezpieczna dla danych binarnych, a pierwszy argument preg_match() nie - moim zdaniem nie ma to sensu. Na szczęście taka sytuacja właściwie nie ma miejsca w praktyce. Jeżeli dane użytkownika trafiają z jakiegoś powodu do wzorca, to bardziej należy się martwić o to, żeby nie istniała możliwość dołączenia modyfikatora &quot;e&quot; w preg_replace(), niż o bajt zerowy.</description>
		<content:encoded><![CDATA[<p>Funkcja preg_match() potraktuje bajt zerowy w przeszukiwanym ciągu jak normalny znak, więc jest pod tym względem znacznie bezpieczniejsza. Nie można przy pomocy bajtu zerowego obejść filtrów bazujących na perlowych wyrażeniach regularnych.</p>
<p>Gdyby bajt zerowy trafił jakoś do wzorca, zostałby jednak potraktowany jako koniec tego wzorca. Nie wiem, dlaczego funkcja preg_quote() jest bezpieczna dla danych binarnych, a pierwszy argument preg_match() nie &#8211; moim zdaniem nie ma to sensu. Na szczęście taka sytuacja właściwie nie ma miejsca w praktyce. Jeżeli dane użytkownika trafiają z jakiegoś powodu do wzorca, to bardziej należy się martwić o to, żeby nie istniała możliwość dołączenia modyfikatora &#8222;e&#8221; w preg_replace(), niż o bajt zerowy.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Autor: Antoni Jakubiak</title>
		<link>http://lukasz.pilorz.net/2007/04/01/xss-hackme-zwyciezca-i-rozwiazania/comment-page-1/#comment-125</link>
		<dc:creator>Antoni Jakubiak</dc:creator>
		<pubDate>Wed, 04 Apr 2007 18:10:32 +0000</pubDate>
		<guid isPermaLink="false">http://lukasz.pilorz.net/index.php/2007/04/01/xss-hackme-zwyciezca-i-rozwiazania/#comment-125</guid>
		<description>Drugie wejście jest super ciekawe. Nie przypuszczałem, że %00 będzie traktowane jako koniec stringu dla erega. A jak zachowają się wyrażenia regularne perlowskie?</description>
		<content:encoded><![CDATA[<p>Drugie wejście jest super ciekawe. Nie przypuszczałem, że %00 będzie traktowane jako koniec stringu dla erega. A jak zachowają się wyrażenia regularne perlowskie?</p>
]]></content:encoded>
	</item>
</channel>
</rss>
