ѕодпишитесь на наш Telegram-канал Ѕудьте в курсе последних новостей 👇 😉 ѕодписатьс€
ѕоддержим в трудное врем€ —пециальное предложение на техническую поддержку вашей »“ - инфраструктуры силами наших экспертов ѕодобрать тариф
ѕоставка оборудовани€ √аранти€ и помощь с настройкой. —кидка дл€ наших читателей по промокоду WIKIMERIONET  упить
»нтерфейс статистики Merion Mertics показывает ключевые диаграммы и графики по звонкам, а также историю звонков в формате, который легко поймет менеджер ѕопробовать бесплатно
¬недрение
офисной телефонии
Ўаг на пути к созданию доступных унифицированных коммуникаций в вашей компании ¬недрить
»нтеграци€ с CRM ѕомогаем навести пор€док с данными
и хранить их в единой экосистеме
ѕодключить
»“ Ѕезопастность ”мна€ информационна€ безопасность дл€ вашего бизнеса «аказать
ћерион Ќетворкс

10 минут чтени€

–азработчики программного обеспечени€ должны держать много информации у себ€ в голове. —уществует множество вопросов, которые нужно задать, когда речь заходит о создании веб-сайта или приложени€:  акие технологии использовать?  ак будет настроена структура?  акой функционал нам нужен?  ак будет выгл€деть пользовательский интерфейс? ќсобенно на рынке программного обеспечени€, где производство приложений больше похоже на гонку за репутацией, чем на хорошо обдуманный процесс, один из важнейших вопросов, который часто остаетс€ на дне У—писка важныхФ:  ак наш продукт будет защищен?

SQL-инъекции и межсайтовый скриптинг XXS

≈сли вы используете надежный, открытый фреймворк дл€ создани€ своего продукта (и, если он доступен и пригоден, почему бы и нет?), тогда базовые проблемы безопасности, как атаки CSFR и кодирование парол€, могут быть уже решены за вас.

“ем не менее, быстро развивающимс€ разработчикам будет полезно освежить свои знани€ о стандартных угрозах, дабы избежать ошибок новичка. ќбычно самое слабое место в безопасности вашего программного обеспечени€ - это вы.

ј кто может заниматьс€ взломом?. ≈сть этичный хакер Ц это тот, кто ищет возможные слабости в безопасности и приватно рассказывает их создател€м проекта.

ј чЄрный хакер, которого так же зовут У¬зломщик (cracker)Ф Ц это тот, кто использует эти слабости дл€ вымогательства или собственного блага.

Ёти два вида хакеров могут использовать одинаковый набор инструментов и, в общем, пытаютс€ попасть в такие места, куда обычный пользователь не может попасть. Ќо белые хакеры делают это с разрешением, и в интересах усилени€ защиты, а не уничтожени€ еЄ. „ерные хакеры Ц плохие реб€та.

¬от некоторые примеры наиболее распространЄнных атаках, которые используют слабости в защите: ¬недрение SQL-кода и межсайтовый скриптинг XXS.


SQL атаки

SQL-инъекци€ (SQLi) - это тип инъекционной атаки, котора€ позвол€ет выполн€ть вредоносные SQL команды, дл€ получени€ данных или вывода из стро€ приложени€. ѕо сути, злоумышленники могут отправл€ть команды SQL, которые вли€ют на ваше приложение, через некоторые входные данные на вашем сайте, например, поле поиска, которое извлекает результаты из вашей базы данных. —айты, закодированные на PHP, могут быть особенно восприимчивы к ним, и успешна€ SQL-атака может быть разрушительной дл€ программного обеспечени€, которое полагаетс€ на базу данных (например, ваша таблица пользователей теперь представл€ет собой пустое место).

¬ы можете проверить свой собственный сайт, чтобы увидеть, насколько он восприимчив к такого рода атакам. (ѕожалуйста, тестируйте только те сайты, которыми вы владеете, так как запуск SQL-кодов там, где у вас нет разрешени€ на это, может быть незаконным в вашем регионе; и определенно, не очень смешно.) —ледующие полезные нагрузки могут использоватьс€ дл€ тестов:

  • ' OR 1='1 оцениваетс€ как константа true, и в случае успеха возвращает все строки в таблице
  • ' AND 0='1 оцениваетс€ как константа false, и в случае успеха не возвращает строк.

  счастью, есть способы ослабить атаки SQL-кода, и все они свод€тс€ к одной основной концепции: не довер€йте вводимым пользователем данным.


—м€гчение последствий SQL-кодов.

„тобы эффективно сдержать атаки, разработчики должны запретить пользовател€м успешно отправл€ть необработанные SQL-команды в любую часть сайта.

Ќекоторые фреймворки сделают большую часть т€желой работы за вас. Ќапример, Django реализует концепцию объектно-рел€ционного отображени€, или ORM с использованием наборов запросов. ћы будем рассматривать их в качестве функций-оболочек, которые помогают вашему приложению запрашивать базу данных с помощью предопределенных методов, избега€ использование необработанного SQL.

ќднако возможность использовать фреймворк никогда не €вл€етс€ гарантией.  огда мы имеем дело непосредственно с базой данных, существуют и другие методы, которые мы можем использовать, чтобы безопасно абстрагировать наши SQL-запросы от пользовательского ввода, хот€ они различаютс€ по эффективности. ќни представлены по пор€дку от более к менее важному:

  1. ѕодготовленные операторы с переменной прив€зкой (или параметризованные запросы)
  2. ’ранимые процедуры
  3. Ѕелый список или экранирование пользовательского ввода

≈сли вы хотите реализовать вышеприведенные методы, то эти шпаргалки - отлична€ отправна€ точка дл€ более глубокого изучени€. ƒостаточно сказать, что использование этих методов дл€ получени€ данных вместо использовани€ необработанных SQL-запросов помогает свести к минимуму веро€тность того, что SQL будет обрабатыватьс€ любой частью вашего приложени€, котора€ принимает входные данные от пользователей, тем самым см€гча€ атаки SQL-кодов.


ћежсайтовые скриптовые атаки (XSS)

≈сли вы €вл€етесь хакером, то JavaScript - это в значительной степени ваш лучший друг. ѕравильные команды будут делать все, что может сделать обычный пользователь (и даже некоторые вещи, которые он не должен делать) на веб-странице, иногда без какого-либо взаимодействи€ со стороны реального пользовател€.

ћежсайтовые скриптовые атаки, или XSS, происход€т, когда код JavaScript вводитс€ на веб-страницу и измен€ет ее поведение. ≈го последстви€ могут варьироватьс€ от по€влени€ непри€тных шуток до более серьезных обходов аутентификации или кражи учетных данных.

XSS может происходить на сервере или на стороне клиента и, как правило, поставл€етс€ в трех вариантах: DOM (Document Object Model - объектна€ модель документа) на основе хранимых и отображаемых XSS. –азличи€ свод€тс€ к тому, где полезна€ нагрузка атаки вводитс€ в приложение.

XSS на основе DOM

XSS на основе DOM возникает, когда полезна€ нагрузка JavaScript вли€ет на структуру, поведение или содержимое веб-страницы, загруженной пользователем в свой браузер. ќни чаще всего выполн€ютс€ через измененные URL-адреса, например, в фишинговых письмах.

„тобы увидеть, насколько легко было бы дл€ введенного JavaScript манипулировать страницей, мы можем создать рабочий пример с веб-страницей HTML. ѕопробуйте создать файл в локальной системе под названием xss-test.html (или любым другим) со следующим кодом HTML и JavaScript:

<html>
    <head>
        <title>My XSS Example</title>
    </head>
    <body>
        <h1 id="greeting">Hello there!</h1>
            <script>
                var name = new URLSearchParams(document.location.search).get('name');
                if (name !== 'null') {
                    document.getElementById('greeting').innerHTML = 'Hello ' + name + '!';
                }
            </script>
        </h1>
</html>

Ќа этой веб-странице будет отображатьс€ заголовок "Hello!Ф если только он не получает параметр URL из строки запроса со значением name. „тобы увидеть работу скрипта, откройте страницу в браузере с добавленным параметром URL, например:

file:///path/to/file/xss-test.html?name=Victoria
Ќаша небезопасна€ страница принимает значение параметра URL дл€ имени и отображает его в DOM. —траница ожидает, что значение будет хорошей дружественной строкой, но что, если мы изменим его на что-то другое? ѕоскольку страница принадлежит нам и существует только в нашей локальной системе, мы можем тестировать ее сколько угодно. „то произойдет, если мы изменим параметр name, скажем, на:
<img+src+onerror=alert("pwned")>
pwned

Ёто всего лишь один пример, который демонстрирует, как может быть выполнена атака XSS. —мешные всплывающие оповещени€ могут быть забавными, но JavaScript может принести много вреда, в том числе помога€ злоумышленникам украсть пароли и личную информацию.

’ранимые и отраженные XSS

’ранимые (stored) XSS возникают, когда полезна€ нагрузка атаки хранитс€ на сервере, например, в базе данных. јтака вли€ет на жертву вс€кий раз, когда эти сохраненные данные извлекаютс€ и отображаютс€ в браузере.

Ќапример, вместо того чтобы использовать строку URL-запроса, злоумышленник может обновить свою страницу профил€ на социальном сайте, чтобы внедрить скрытый сценарий, скажем, в раздел Уќбо мнеФ. —ценарий, неправильно сохраненный на сервере сайта, будет успешно выполн€тьс€ всЄ врем€, пока другой пользователь просматривает профиль злоумышленника.

ќдним из самых известных примеров этого €вл€етс€ червь Samy, который практически захватил MySpace в 2005 году. ќн распростран€лс€ путем отправки HTTP-запросов, которые копировали его на страницу профил€ жертвы вс€кий раз, когда просматривалс€ зараженный профиль. ¬сего за 20 часов он распространилс€ на более чем миллион пользователей.

ќтраженные (reflected) XSS аналогично возникают, когда введенные данные перемещаютс€ на сервер, однако вредоносный код не сохран€етс€ в базе данных. ¬место этого он немедленно возвращаетс€ в браузер веб-приложением.

ѕодобна€ атака может быть осуществлена путем заманивани€ жертвы дл€ перехода по вредоносной ссылке, котора€ отправл€ет запрос на сервер у€звимого веб-сайта. «атем сервер отправит ответ злоумышленнику, а также жертве, что может привести к тому, что злоумышленник сможет получить пароли или совершить действи€, которые €кобы исход€т от жертвы.


ќслабление XSS

¬о всех этих случа€х XSS могут быть сдержаны с помощью двух ключевых стратегий: проверка полей формы и предотвращение пр€мого ввода данных пользователем на веб-странице.

ѕроверка полей формы

‘реймворки снова могут нам помочь, когда речь заходит о том, чтобы убедитьс€, что представленные пользователем формы наход€тс€ в актуальном состо€нии. ќдин из примеров - встроенные классы полей Django, которые предоставл€ют пол€, провер€ющие некоторые часто используемые типы, а также задают нормальные значени€ по умолчанию.

Ќапример, поле электронной почты Django использует набор правил, чтобы определить, €вл€етс€ ли предоставленный ввод действительным письмом. ≈сли отправленна€ строка содержит символы, которые обычно не присутствуют в адресах электронной почты, или если она не имитирует общий формат адреса электронной почты, то Django не будет считать это поле допустимым и форма не будет отправлена.

≈сли вы не можете полагатьс€ на фреймворк, можете реализовать вашу собственную проверку входных данных. Ёто можно сделать с помощью нескольких различных методов, включа€ преобразование типа, например, гарантиру€, что число имеет тип int(); проверка минимальных и максимальных значений диапазона дл€ чисел и длин строк; использование заранее определенного массива вариантов, который позвол€ет избежать произвольного ввода, например, мес€цев года; и проверка данных на соответствие строгим регул€рным формулировкам.

  счастью, нам не нужно начинать все с нул€. ѕомогут доступные ресурсы с открытым исходным кодом, такой как валидаци€ репозитори€ регул€рных выражений OWASP, который предоставл€ет шаблоны дл€ сопоставлени€ их с некоторыми распространенными формами данных. ћногие €зыки программировани€ предлагают библиотеки проверки, специфичные дл€ их синтаксиса, и мы можем найти множество таких библиотек на GitHub.

’от€ это и может показатьс€ утомительным, правильно реализованна€ проверка ввода может защитить наше приложение от восприимчивости к XSS.

ѕредотвращение пр€мого ввода данных

Ёлементы приложени€, которые непосредственно возвращают пользовательский ввод в браузер, при обычной проверке могут быть неочевидны. ћы можем определить области приложени€, которые могут быть подвержены риску, изучив несколько вопросов:

  1.  ак происходит поток данных через приложение?
  2. „то ожидает пользователь, когда он взаимодействует с этими входными данными?
  3. √де на нашей странице по€вл€ютс€ данные? —танов€тс€ ли они встроенными в строку или атрибут?

¬от некоторые примеры полезных нагрузок, с которыми мы можем поиграть, чтобы проверить входные данные на нашем сайте (оп€ть же, только на нашем собственном сайте!). ”спешное выполнение любого из этих образцов может указывать на возможную у€звимость к XSS из-за пр€мого ввода данных.

  • "><h1>test</h1>
  • '+alert(1)+'
  • "onmouserover="alert(1)
  • http://"onmouseover="alert(1)

 ак правило, если вы можете обойти пр€мой ввод данных, сделайте это.  роме того, убедитесь, что вы полностью понимаете эффективность выбранных методов; например, использование innerText вместо innerHTML в JavaScript гарантирует, что содержимое будет задано как обычный текст вместо (потенциально у€звимого) HTML.


јккуратнее с вводом!

–азработчики программного обеспечени€ €вно наход€тс€ в невыгодном положении, когда речь заходит о конкуренции с черными хакерами. Ќесмотр€ на всю проделанную работу по защитите каждого ввода, который потенциально может скомпрометировать наше приложение, злоумышленнику достаточно только найти тот, который мы пропустили. Ёто все равно что установить засовы на всех двер€х, но оставить окно открытым!

ќднако, научившись мыслить в том же ключе, что и злоумышленник, мы можем лучше подготовить наше программное обеспечение к противосто€нию плохим парн€м.  ак бы ни было интересно добавл€ть функции как можно быстрее, мы избежим большого количества долгов по кибербезопасности, если заранее продумаем поток нашего приложени€, проследим за данными и обратим внимание на наши входные данные.