ХАКЕРИ в Internet — сайтът се доверява на

Скачать презентацию ХАКЕРИ в Internet — сайтът се доверява на

f4cf9a60810c60531179d9c09d45d71e.ppt

Количество слайдов: 17

ХАКЕРИ в Internet - сайтът се доверява на външен (несигурен) източник; -сайтът изобразява input като output: Helo, <% Response. Write(Request. Querystring(“name”)) %> Тогава, например, нормална потребителска заявка, която включва input (включен в заявката към сървър) може да изглежда така: www. conto. com/req. asp? name=Ivan

Не толкова добре ще е ако хакер е вмъкнал код, който уж предоставя възможност за link към същия (доверен) site, а всъщност създава предпоставка за генериране на заявка от вид : Click here to win $1 000 и блокът: “scriptcode” например изглежда така (което е сравнително безобидно): А за да не види нищо жертвата (заблуденият user на сайта), блокът може да изглежда и така: click here to win $1 000 (това е същото като по-горе, но маскирано в ESC пследователности на символите) натрапникът може да използва и малко известен , но валиден URL формат: http: //username: password@webserver Тогава частта www. microsoft. com се интерпретира като username, следвана от истинския Web site, при това кодиран, та user’ът да не подозре нищо.

Изобщо, използваното по-горе поле ‘name’ може да съдържа не име, а HTML или дори Java. Script, с които да се изпълни достъп до потребителски данни, например: потребителското cookie. Cookies са винаги свързани с домейна под чието ръководство са били създадени. ( Напр. Cookies, свързани с домейн conto. com ще са достъпни само от страници на този домейн и от никой друг. Когато user кликне на link както беше в примера, кодът е свален от conto. com и изпълнява достъп до cookies от домейна conto. com. Само 1 “лоша”страница, вързала се към домейна, ще е достатъчна за да стане той несигурен. (могат да се вземат неподозирано данни от чуждия сайт и да се прехвърлят към хакерския) Значи чрез XSS, cookies могат да се четат и променят. Така и с всичко привързано към домейна (Active. X контроли, RPC и др) Хакерът може да вгради “измамен” сайт, стига да има XSS пробив (spoofing). Напр псевдо “news site Web server”. Потребител кликва на link , и неговия обектен модел и security context става достъпен. Той може дори да получи “псевдо-новини”, доставени му от site на атакуващия

Какво всъщност става хакер Какво изглежда на потребител жертва web site 1. изпраща например e-mail с link към web site 2. user кликва на link доставен от атакуващия кликването препраща към друг site отговорът са някакви 3. script се изпълнява в context на сайта на жертвата данни за заблуда потребителя как XSS (cross site scripting) атаките работят

ето код, който след кликване на link, изпраща cookie’то на userа към друг сайт (зададен от хакера): > Вмъква форма със скрито поле Кликни тук и печелиш! Прави това, което не трябва. Взима лична информация и я submit Причината правеща възможни XSS атаките е че код и данни са примесени заедно

Някои бележки: 1. имайки достъп до cookie, хакерът може да го зарази (със свой добавен код) и всеки път впоследствие, когато потребителят кликне link към въпросния сайт, скриптът ще се изпълнява. 2. XSS атаки могат да се извършат и зад firewall (конфигуриран така че сървърите вътре са trusted, а вън ‘not trusted’): по описаната схема, хакерски сървър отвън подлъгва вътрешен клиент (че е вътрешен), кара го да изпълни нещо и … Единственото което трябва е да знае хакерът е име на сървър зад защитната стена, който да поддържа собствени слаби проверки. 3. ако сайтът е написан така, че въведени от потребител данни се вместват директно в скрипт на същата страница, хакерът е допълнително облекчен: даже не е нужно да добавя свой (извежда всичко което е след символа # в URL полето. ) Тогава хакер , знаейки мястото на този стандартен файл и начина за извикването му (напр. с какви параметри, index или др. той се вика от другите страници на help средата), може сам да го стартира с подаден свой скрипт: file: //C: webfileslocalxss. html#

XSS атаки срещу HTML ресурси Освен http: IE поддържа и други протоколи. Протоколът res: позволява извличане и работа с ресурси (картинки, HTML файл, текстове) от DLL, EXE и други в двоичен формат. Например допустим е следния запис: res: //mydll. dll/#23/ERROR С горното се извлича и изобразява на дисплей HTML (#23) ресурс с име ERROR от mydll. dll Ако в него се очаква потребителски вход, очевидно (както вече бе показано) може да се стартира XSS атака. Затова, гледайте на ресурсите, съдържащи в себе си HTML данни като на същински HTML файл! XSS атаки срещу компилирани Help файлове Наистина, те са компилирани и са с друг формат и разширение CHM. Лесно обаче се декомпилират. Те пък са уязвими през протокол mk:

Спасения от XSS атаки 1. точно фиксиране на input информацията (в HTML, граматиката е огромна, някой символи са със специално значение и се използват от хакерите). 2. кодирайте въведените от потребителя данни, преди да се изведат като част от заявка. За целта може да се ползва: в ASP Server. HTMLEncode(); в ASP. NET Http. Server. Utility. HTMLEncode(). С това опасните символи се преобразуват в безопасни HTML техни заместители, напр. < става < 3. добавяйте “ ” около пропъртита на тагове. Пример с ASP код: > очаква стойност за id и генерира заявка, например: Всичко е ОК при вход 2105. Но при потребителски злонамерен input от вида: 2105> се стартира и друг код. или още по-просто – ако се въведе в полето: 2105 onclick=”вреден код” вредният код ще се изпълни при кликване на линка. Тогава:

Известно спасение е да обградите с “ ” всеки опасен атрибут (както в примера) Например: ”> Тогава лесно в обработващия asp код (стартиран от завката) ще може да се открие края на низа за полето id. Целият низ се възприема като неделима част и се подава през заявката към кода в. asp файла. Там лесно ще отфилтрира полезната част, преди да се позволи да се изпълни каквото и да е от него – например вмъкнат вреден script. Например при въвеждане на : 2105 onclick=’вреден код’ ще се породи заявката: и. asp кодът лесно ще отдели нужния id от низовия блок: ( едва ли това след числото е код на продукт) 2105 onclick=’вреден код’ ( Защо “ ”, а не ‘ ? Защото кодировките на HТМL вкарват в ESC-последователност “ ” и не вкарват в такава ‘, което ни защитава в случаите когато хакер вмъква ESC последователност на вредния си код )

4. вкарвайте данни от потребителския вход в property inner. Text. Там те са инертни (не могат да се стартират)и следователно безопасни Пример: … Дори ако към URL низа се вмъкне нещо от злонамерен потребител, нещата са безопасни. Пример: file: //C: webfiles/xss. html# нищо от вредния скрипт не би се изпълнило.

5. ограничете валидните символи с codepage. Taka част от специалните символи в клиентска заявка, които могат да са източник на хакерски опасности ще отпаднат. Тази кодова страница поддържа повечето западни езици. Има и други: 8859 -2 за източна Европа; 8859 -3 за югоизточна Европа; 8859 -5 за кирилица и т. н. . 6. Защитете своите cookies от XSS атаки. Добавяте опцията Http. Only в текста за cookie’то: Set-Cookie: name=Ivan; domain=Microsoft. com; Http. Only Всеки опит на скрипт код, получен от сървър да прочете document. cookie пропъртито, ще върне празен низ (за IE след версия 6). Можете да напишете script – филтър, който да формира правилно всяко cookie. За целта в ASP метод Response. Set. Header(), в ASP. NET: методите на обекта Http. Cookie за формиране на cookie и Response. Cookies. Add(формирано cookie). (за съжаление с това ограничение се спира само четенето, а не заразяване на cookies чрез добавяне)

7. Използвайте атрибута добавен в IE 6 Той позволява въвеждане на защитите, описани в “zone setting” към файлове, включени във фрейм. Например: вкарва целия сайт в Restricted Sites zone, където по подразбиране скрипт не се изпълнява. 8. Само избягването на “несигурни “ конструкции няма да ви спаси Често разработчици се ограничават само до “сигурни”, т. е HTML - конструкции. Без скрипт. Но XSS опасността е именно в това че може да се вмъкне скрипт и в тях. Ето примери: