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

f4cf9a60810c60531179d9c09d45d71e.ppt

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

ХАКЕРИ в Internet - сайтът се доверява на външен (несигурен) източник; -сайтът изобразява input ХАКЕРИ в 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: [email protected] Тогава частта www. microsoft. com се интерпретира като username, следвана от истинския Web site, при това кодиран, та user’ът да не подозре нищо.

Изобщо, използваното по-горе поле ‘name’ може да съдържа не име, а HTML или дори Изобщо, използваното по-горе поле ‘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. изпраща например Какво всъщност става хакер Какво изглежда на потребител жертва web site 1. изпраща например e-mail с link към web site 2. user кликва на link доставен от атакуващия кликването препраща към друг site отговорът са някакви 3. script се изпълнява в context на сайта на жертвата данни за заблуда потребителя как XSS (cross site scripting) атаките работят

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

XSS атаки срещу HTML ресурси Освен http: IE поддържа и други протоколи. Протоколът res: 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:

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

5. ограничете валидните символи с codepage. Taka част от специалните символи в клиентска заявка, 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. Използвайте атрибута <FRAME SECURITY> добавен в IE 6 Той позволява въвеждане на защитите, 7. Използвайте атрибута добавен в IE 6 Той позволява въвеждане на защитите, описани в “zone setting” към файлове, включени във фрейм. Например: вкарва целия сайт в Restricted Sites zone, където по подразбиране скрипт не се изпълнява. 8. Само избягването на “несигурни “ конструкции няма да ви спаси Често разработчици се ограничават само до “сигурни”, т. е HTML - конструкции. Без скрипт. Но XSS опасността е именно в това че може да се вмъкне скрипт и в тях. Ето примери: и много , много други. Някои са валидни за IE, други за Navigator, Mozilla, Opera, а много от тях за всички !!!

9. Идеята да се преобразува целия input към големи букви (защото, видите ли, JScript 9. Идеята да се преобразува целия input към големи букви (защото, видите ли, JScript е case-sensitive, primary lowercase) не е спасение. Ами ако атаката е с Microsoft Visual Basic, който е case-insensitive!!! 10. Заграждането с ‘ или “ също не е панацея: много HTML конструкции ги премахват автоматично 11. Аko просто забраните таговете jscript, vbscript, javascript, и това няма да ви спаси: Netscape Navigator поддържа още и livescript: mocha: както и &{} за скриптове. ПРОСТО СТРИКТНО ПРОВЕРЯВАЙТЕ ВХОДНИЯ ТЕКСТ !!!

Преход към следващата тема: Injection атаки и основни принципи на защита от ‘injection’атаки Принцип Преход към следващата тема: Injection атаки и основни принципи на защита от ‘injection’атаки Принцип Какво да се направи Never trust user input Валидизация на всички textbox полета, най-добре чрез готови validation controls, regular expressions, code и т. н. Never use dynamic SQL Използване на parameterized SQL или stored procedures Never connect to a database using an admin-level account Използване на ‘limited access account’ при свързване с БД Don't store secrets in plain text Криптиране на passwords и всички съществени данни, както и на connection strings Exceptions should divulge minimal information Не подавайте ненужно много информация при error messages; ползвайте готови контроли (напр. custom. Errors) за да дадете мин. Информация в случаите на unhandled error

Опасности при използване на ISAPI функции • Internet Server API използвани за създаване на Опасности при използване на ISAPI функции • Internet Server API използвани за създаване на сървърни разширения и филтри, са най-опасните технологии, защото код се пише на ниско ниво (С/С++) и се реализира достъп или обработка или филтрации на web заявки/отговори и на системна информация. • следва примерен код с грешка от разширяване граници на буфер ( buffer overrun): (напомням, че ISAPI код се изпълнява в процес Inetinfo. exe, който е системен процес – следователно има концептуална грешка: user input се изпълнява на системно ниво!!!) TCHAR g_wsz. Host. Name[MAX_LEN + 1]; BOOL Get. Host. Name(EXTENSION_CONTROL_BLOK *p. ECB) { DWORD dw. Size = sizeof(g_wsz. Host. Name); Char sz. Host. Name[MAX_LEN + 1]; // Get the server name // p. ECB Get. Server. Variable retrieves info about HTTP connection&IIS itself // dw. Size is the size of the buffer to copy requested info into p. ECB Get. Server. Variable(p. ECB Conn. ID, ”SERVER_NAME, sz. Host. Name, &dw. Size); ……. TCHAR при UNICODE се преобразува в WCHAR. Следователно, dwsize и sz. Host. Name са с различна дължина ! В междината хакер може да ‘набута’ свой код и той да попадне в системен процес! Освен това буфера sz. Host. Name е последен в стека на ф-ията и след него е възвратния адрес!!!! Ако той се подмени!!!