Атаки на веб через управление сессиями.

Обновлено 09.11.2025 06:45

Атаки на веб-приложения через систему управления сессиями.

Еще одним уязвимым местом являются веб-приложения. Конечно, разработка корпоративных веб-порталов обычно поручается профессионалам - веб-программистам, но системный администратор и тем более специалист по ИБ должны иметь представление о существующих уязвимостях в веб-при ложениях. Кроме того, в небольших компаниях сисадмин зачастую занимается разработкой и поддержкой корпоративного портала. Так что приведенная далее информация будет полезна многим.

Современные веб-порталы используют в качестве веб-сервера преимущественно Apache. Существует, конечно, IIS (Internet Information Services), работающий под Windows, но большинство хостингов все равно используют связку FreeBSD/Linux+Apache. Для хранения данных, с которыми работает веб-портал, обычно используется MySQL или PostgreeSQL. В высоконагруженных промышленных системах может применяться Oracle.

В качестве языка сценариев обычно используется PHP или Perl. Существуют также высокоуровневые средства разработки портальных решений от Microsoft, но в данном разделе мы не будем их касаться в силу меньшей их распространенности, по сравнению с бесплатными FreeBSD, Apache, MySQL, PHP.

В качестве практического примера рассмотрим атаки на PHP-приложение через систему управления сессиями. Основными причинами возможности данных атак являются отсутствие проверки идентификатора сессии пользователя и отсутствие проверки данных, хранящихся в сессии.

Рассмотрим возможные варианты атак на приложение.

Кража сессии (Session Hijacking).

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

Общий алгоритм осуществления атаки следующий:

1) атакующий собирает информацию об IP-адресах жертвы и том ресурсе, доступ к которому необходимо получить;

2) затем необходимо дождаться, когда атакуемый подключится к целевому ресурсу;

3) далее злоумышленнику нужно запустить ARP relay;

4) когда жертва подключилась к целевому ресурсу и начала работу с ним, атакующий увидит в сниффере новое активное соединение. Далее взломщик производит атаку десинхронизацией TCP/IP, которая уже описывалась ранее. Соединение жертвы «отваливается» с помощью принудительной отправки RST-пакета;

5) далее злоумышленник может работать от имени жертвы и с ее учетными Правами;

6) атакуемый вынужден заново переподключиться к целевому ресурсу, справедливо полагая, что произошел аппаратный сбой соединения. Злоумышленник отправляет ему RST;

7) когда хакер закончит работу с системой, он прекращает посылать RST и отключает ARP-relay;

8) взломанный пользователь снова может работать с системой.

Как нетрудно понять из описания, для реализации такой атаки необходимо быть подключенным к одному коммутатору, что и атакуемый. То есть фактически находиться в одной локальной сети с жертвой.

В более простом случае злоумышленник может попробовать взломать чужую сессию с помощью подмены cookies.

Вот небольшой пример подобной атаки на практике.

Для ее реализации необходимы сниффер, например Wireshark, браузер (например, Firefox) и редактор Cookies (можно использовать add-on к Firefox).

Атакуемый пользователь осуществляет подключение к порталу социальной сети.

Взломщик производит сниффинг трафика. По окончании перехвата трафика злоумышленнику необходимо найти переданные пользователем cookies. Сделать это в Wireshark можно следующим образом. Нажать Ctrl+F или Edit - Find Packet. В поле By: необходимо выбрать String и Search In, опцию Packet details, в текстовом поле нужно указать Set-Cookie.

Когда нужный пакет будет найден, необходимо нажать правую кнопку мыши и выбрать «Follow TCP Stream». Далее в этом потоке можно обнаружить пакет, аналогичный приведенному.

Это и есть необходимый cookie. Далее нужно открыть редактор Cookie Editor (Tools - Cookie Editor). Потом нажать Add и указать следующее:

Name: _twitter_sess

Content: copy paste the information from the TCP Stream (see the red box in the Session Cookie Found from TCP Stream picture)

Domain: .twitter.com

Path: /

В случае успешной реализации теперь для входа на сайт злоумышленнику не требуется указывать учетные данные, достаточно просто зайти на страницу.

Кратко выполняются следующие действия:

1) перехват трафика;

2) обнаружение пакета, содержащего Set-Cookie;

3) установка Cookie в редакторе Cookie Editor add-on;

4) обращение к нужному сайту.

Фиксация сессии (Session Fixation).

Для осуществления этой атаки злоумышленнику не нужен идентификатор чужой сессии, достаточно установить идентификатор своей сессии легальному пользователю, прошедшему авторизацию. Как и в предыдущем случае, создается ситуация, когда злоумышленник и легальный пользователь имеют один и тот же идентификатор сессии.

Фиксация сессии (Session Fixation) представляет собой метод нападения, который принудительно устанавливает идентификатор сессии в определенное значение. В зависимости от функциональности атакуемого сайта, чтобы «зафиксировать» идентификатор сессии, может быть применено множество различных методов. Затем идентификатор пользовательской сессии фиксируется, и злоумышленник ожидает тех, кто будет входить в систему. Как только пользователь сделает это, злоумышленник использует предопределенное значение идентификатора сессии, чтобы получить его онлайн-идентификацию со всеми вытекающими последствиями.

Существует два типа систем управления сессиями: «свободные» и «строгие». Тип сессии определяется в зависимости от того, как формируются значения идентификаторов. Первый тип систем позволяет веб-браузерам указывать любой идентификатор. Второй тип систем принимает только значения, сформированные на сервере. В свободных системах произвольный идентификаторсессии обрабатывается вообще без обращения к веб-сайту. Строгие системы требуют от злоумышленника обслуживания «сессии-ловушки» с периодическим обращением к веб-сайту для предотвращения тайм-аутов по неактивности.

Без активной защиты от фиксации сессии атака может быть предпринята против любого веб-сайта, использующего сессии для идентификации подлинности пользователей. Веб-сайты, использующие идентификаторы сессий, обычно применяют Cookie, также применяются URL и скрытые поля форм. К сожалению, сессии, основанные на Cookie, проще для нападений.

В отличие от похищения идентификаторов сессий пользователей, выполняемых после их входа на веб-сайт, фиксация сессии предоставляет значительно более широкие возможности для нападения. Активная часть нападения делается до входа пользователей в систему.

Рассмотрим пример классической фиксации пользовательской сессии.

Существуют три этапа фиксации:

1) установка;

2) фиксация;

3) вхождение.

На первом этапе злоумышленник устанавливает «сессию-ловушку» на атакуемый сайт и получает этот идентификатор сессии. Или злоумышленник для нападения может выбрать случайный идентификатор сессии. Но в этом случае значение, установленное сессией-ловушкой, должно поддерживаться (чтобы «быть живым») с повторными соединениями с веб-сайтом.

Затем на следующем этапе злоумышленник помещает значение сессии-ловушки в браузер пользователя и фиксирует идентификатор пользовательской сессии. И на третьем этапе злоумышленник ожидает, пока пользователь не войдет в систему атакуемого сайта. Как только пользователь делает это, значение фиксированного идентификатора сессии будет использовано, и злоумышленник может начать работу со взломанной системой.

Для фиксации идентификатора пользовательской сессии может быть выполнен один из следующих методов:

выдача cookie с использованием клиентского скрипта;

выдача нового значения идентификатора сессии в cookie с использованием клиентского скрипта. Межсайтовое программирование в слабых местах системы защиты веб-сайта может быть использовано для изменения текущего значения cookie.

http://example/<script>document.cookie="sessionid=1234;%20domain=.example.сom";</script>.idc

Вот пример выдачи cookie с использованием МЕТА-тега. Этот метод эффективен, особенно когда блокиратор межсайтового программирования предотвращает инъекцию тегов HTML-скриптов, но не META-тегов.

http://example/<meta%20http-equiv=Set-Cookie%20content="sessionid=1234;%20domain=.example.сom">.idc

Выдача cookie c использованием HTTP-заголовка ответа.

Злоумышленник вызывает или на целевом веб-сайте, или на любом из его поддоменов выдачу cookie с идентификатором сессии. Это может быть выполнено разными путями:

взлом веб-сервера в домене (например, плохо поддерживаемый сервер);

заражение пользовательского DNS-сервера, практически с добавлением веб-сервера злоумышленника в атакуемый домен (этот тип атак уже описывался чуть в постах, посвященном DNS);

установка злонамеренного веб-сервера в атакуемый домен (например, на рабочей станции в Windows2000 домен, все рабочие станции также находятся в DNS-домене);

использование атаки разбиение HTTP-ответа.

Здесь также стоит отметить, что длительная атака фиксации сессии может быть выполнена выдачей постоянных cookies (например, со временем жизни 10 лет), которые будут держать фиксацию сессии даже после перезагрузки пользователем компьютера. Вот пример:

http://example/<script>document.cookie="sessionid=1234;%20Expires=Friday,%201-Jan2017%2000:00:00%20GMT";</script>.idc

Отравление сессии (Session Poisoning).

Угроза отравленной сессии возникает, если злоумышленник имеет возможность установить свой PHP-сценарий на сервере, где исполняется атакуемое приложение. Суть атаки заключается в том, что если PHP-приложения исполняются на одном сервере, то велика вероятность того, что, зная идентификатор сессии, злоумышленник сможет работать с данными сессии, созданной в атакуемом приложении. Отравление возможно, если атакуемое приложение имеет ошибку, позволяющую выполнять произвольный код, и если веб-приложение работает на сервере вместе с приложениями других пользователей хостинга.

Цель данной атаки - получение доступа к значениям сессии с возможностью чтения/записи. В случае успеха злоумышленник сможет читать и/или фальсифицировать любое значение, хранящееся в сессии. Отравления используют для получения персональных данных других пользователей, а также для модификации собственной сессии, для выдачи себя за другого и/или повышения привилегий.

Вот простейший пример данной атаки:

$var = $_GET["something"];

$_SESSION["$var"] = $var2;

Аутентификация с помощью форм.

Когда клиент заходит на страницу и вводит логин и пароль, его учетные данные передаются на сервер. В случае если аутентификация успешно пройдена, сервер формирует сессионный билет для данного пользователя и при всех последующих обращениях к серверу используется уже этот билет, данные которого сохраняются в cookie. По умолчанию время жизни билета составляет 30 минут. По окончании этого времени билет может быть автоматически продлен. В случае если в течение определенного интервала времени обращений больше не было, сервер отправляет клиенту сообщение с предложением «забыть» этот билет, в результате чего браузер удаляет данный cookie, и пользователю надо заново вводить учетные данные, чтобы войти в систему.

Казалось бы, все вполне логично и правильно. Но клиент (а точнее, злоумышленник) может периодически просить сервер продлевать свой билет, по сути неограниченное число раз. То есть сервер никак не контролирует, какое количество раз продлевался билет. И злоумышленник может просто игнорировать полученное от сервера предложение «забыть» свой билет и продолжать продлевать его и дальше.

Таким образом, если злоумышленник смог похитить cookie с билетом, он сможет использовать пользовательскую сессию.

Cross Site Request Forgery.

Старый добрый CSRF актуален и для .NET. Напомним, что CSRF - это вид атак на посетителей веб-сайтов, использующий недостатки протокола HTTP. Если жертва заходит на сайт, созданный злоумышленником, от ее лица тайно отправляется запрос на другой сервер (например, на сервер платежной системы), осуществляющий некую вредоносную операцию (например, перевод денег на счет злоумышленника).

Для осуществления этой атаки должно быть выполнено несколько условий. Во-первых, жертва должна быть аутентифицирована на том сервере, на котором выполняется запрос. Также этот запрос не должен требовать какого-либо

подтверждения со стороны пользователя, которое не может быть автоматизировано, то есть которое не может быть подделано атакующим скриптом.

В качестве примера рассмотрим ситуацию, когда пользователь входит в систему с помощью проверки подлинности на основе тех самых форм, о которых мы говорили чуть раньше. Сервер выполняет проверку подлинности пользователя и выдает ответ, включающий билет пользователя в cookie. При этом сайт банка доверяет любому запросу, который он получает с допустимым билетом в cookie. Далее пользователь, не завершая принудительно сессию на сайте банка, посещает другой сайт, www.hacker.com, который содержит HTML-форму, в которой запрятана отправка в форме следующих данных:

</form>

Обратите внимание, что форма отправит данные именно на сайт банка. Это «межсайтовая» часть CSRF. Далее под каким-либо предлогом пользователю предлагается нажать кнопку, которая скрытно отправит данные формы. При отправке формы браузер автоматически отправит и билет в cookie для запрошенного домена, ведь пользователь формально еще залогинен на сайте банка. В результате запрос будет выполнен на сайте банка. Стоит отметить, что использование HTTPS не предотвращает атаки CSRF. Вредоносный сайт может отправлять запрос так же легко, как и небезопасный запрос.

Такие атаки становятся возможными благодаря тому, что в браузере хранятся cookie, выданные приложением, эти cookie содержат в том числе сеансовые билеты прошедших проверку пользователей, и наконец браузер отправляет веб-приложению все cookie, связанные с доменом, независимо от того, как запрос к приложению был создан в браузере.

Петухов Олег, юрист в области международного права и защиты персональных данных, специалист в области информационной безопасности, защиты информации и персональных данных.

Телеграм-канал: https://t.me/zashchitainformacii

Группа в Телеграм: https://t.me/zashchitainformacii1

Сайт: https://legascom.ru

Электронная почта: online@legascom.ru

#защитаинформации #информационнаябезопасность

Attacks on the web through session management.

Attacks on web applications through the session management system.

Another vulnerable point is web applications. Of course, the development of corporate web portals is usually entrusted to professional web programmers, but a system administrator and especially an information security specialist should be aware of existing vulnerabilities in web applications. In addition, in small companies, the sysadmin often develops and maintains a corporate portal. So the following information will be useful to many.

Modern web portals primarily use Apache as a web server. There is, of course, IIS (Internet Information Services) running on Windows, but most hosting services still use a combination of FreeBSD/Linux+Apache. MySQL or PostgreeSQL is usually used to store the data that the web portal works with. Oracle can be used in high-load industrial systems.

PHP or Perl is usually used as a scripting language. There are also high-level tools for developing portal solutions from Microsoft, but in this section we will not touch on them due to their lower prevalence compared to free FreeBSD, Apache, MySQL, PHP.

As a practical example, consider attacks on a PHP application through a session management system. The main reasons for the possibility of these attacks are the lack of verification of the user's session ID and the lack of verification of the data stored in the session.

Let's look at possible attacks on the application.

Session Hijacking.

The essence of the attack is that an attacker uses a session identifier belonging to a legitimate user to impersonate the session owner. You can find out the ID of someone else's session by intercepting the traffic of a legitimate user, organizing an XSS attack, or by brute force.

The general algorithm of the attack is as follows:

1) the attacker collects information about the victim's IP addresses and the resource to be accessed.;

2) then you need to wait for the attacker to connect to the target resource.;

3) next, the attacker needs to launch ARP relay;

4) when the victim has connected to the target resource and started working with it, the attacker will see a new active connection in the sniffer. Next, the hacker performs a TCP/IP desynchronization attack, which was already described earlier. The victim's connection "falls off" by forcibly sending an RST packet;

5) further, the attacker can work on behalf of the victim and with her account rights;

6) the attacker is forced to reconnect to the target resource, rightly believing that a hardware connection failure has occurred. The attacker sends him an RST;

7) when the hacker finishes working with the system, he stops sending RST and disables ARP-relay;

8) The hacked user can work with the system again.

As it is easy to understand from the description, in order to implement such an attack, it is necessary to be connected to the same switch as the attacked one. In other words, they are actually on the same local network as the victim.

In a simpler case, an attacker may try to hack someone else's session by spoofing cookies.

Here is a small example of such an attack in practice.

To implement it, you need a sniffer, such as Wireshark, a browser (such as Firefox), and a Cookie editor (you can use add-on to Firefox).

The attacked user connects to the social network portal.

The hacker sniffs the traffic. After the traffic interception is completed, the attacker needs to find the cookies transmitted by the user. You can do this in Wireshark as follows. Press Ctrl+F or Edit - Find Packet. In the By: field, select String and Search In, the Packet details option, and specify the Set Cookie in the text field.

When the desired packet is found, right-click and select "Follow TCP Stream". Further in this stream, you can find a package similar to the one shown.

This is the necessary cookie. Next, you need to open the Cookie Editor (Tools - Cookie Editor). Then click Add and specify the following:

Name: _twitter_sess

Content: copy paste the information from the TCP Stream (see the red box in the Session Cookie Found from TCP Stream picture)

Domain: .twitter.com

Path: /

In case of successful implementation, the attacker now does not need to provide credentials to log in to the site, just go to the page.

The following actions are briefly performed:

1) traffic interception;

2) detecting a package containing a Set Cookie;

3) setting Cookies in the Cookie Editor add-on;

4) accessing the desired site.

Session Fixation.

To carry out this attack, the attacker does not need the identifier of someone else's session, it is enough to set the identifier of his session to a legitimate user who has passed authorization. As in the previous case, a situation is created when an attacker and a legitimate user have the same session identifier.

Session Fixation is a method of attack that forcibly sets the session identifier to a specific value. Depending on the functionality of the attacked site, many different methods can be used to "fix" the session ID. Then the user session ID is fixed, and the attacker waits for those who will log in. As soon as the user does this, the attacker uses the predefined value of the session ID to obtain his online identification with all the ensuing consequences.

There are two types of session management systems: "free" and "strict". The session type is determined depending on how the identifier values are generated. The first type of system allows web browsers to specify any identifier. The second type of system accepts only values generated on the server. In free systems, an arbitrary session identifier is processed without accessing the website at all. Strict systems require an attacker to maintain a "trap session" with periodic access to the website to prevent inactivity timeouts.

Without active protection against session fixation, an attack can be launched against any website that uses sessions to authenticate users. Websites that use session identifiers usually use cookies, and URLs and hidden form fields are also used. Unfortunately, Cookie-based sessions are easier to attack.

Unlike stealing user session IDs performed after they log on to a website, session fixation provides significantly greater opportunities for attack. The active part of the attack is done before users log in to the system.

Let's look at an example of classic user session fixation.

There are three stages of fixation:

1) Installation;

2) fixing;

3) entry.

At the first stage, the attacker installs a "trap session" on the attacked site and obtains this session identifier. Or an attacker can choose a random session ID to attack. But in this case, the value set by the trap session must be maintained (in order to "be alive") with repeated connections to the website.

Then, in the next step, the attacker places the value of the trap session in the user's browser and captures the user session ID. And at the third stage, the attacker waits until the user logs into the system of the attacked site. As soon as the user does this, the value of the fixed session identifier will be used, and an attacker can start working with the hacked system.

To fix the user session ID, one of the following methods can be performed:

issuing cookies using a client script;

issuing a new session ID value in a cookie using a client script. Cross-site programming in weak points of the website protection system can be used to change the current cookie value.

http://example /<script>document.cookie="sessionid=1234;%20domain=.example.com";</script>.idc

Here is an example of issuing a cookie using a META tag. This method is effective, especially when the cross-site programming blocker prevents the injection of HTML script tags, but not META tags.

http://example /<meta%20http-equiv=Set-Cookie%20content="sessionid=1234;%20domain=.example.com">.idc

Issuing cookies using the HTTP response header.

An attacker causes either a cookie with a session ID to be issued on the target website or on any of its subdomains. This can be done in different ways:

hacking a web server in a domain (for example, a poorly maintained server);

infection of a user's DNS server, practically with the addition of an attacker's web server to the attacked domain (this type of attack has already been described in the DNS posts);

installing a malicious web server in the attacked domain (for example, on a workstation in the Windows2000 domain, all workstations are also located in the DNS domain);

using an HTTP response splitting attack.

It is also worth noting here that a long-term session fixation attack can be performed by issuing permanent cookies (for example, with a lifetime of 10 years), which will keep the session fixed even after the user restarts the computer. Here is an example:

http://example/<script>document.cookie="sessionid=1234;%20Expires=Friday,%201-Jan2017%2000:00:00%20GMT";</script>.idc

Session Poisoning.

The threat of a poisoned session occurs if an attacker has the opportunity to install his PHP script on the server where the attacked application is running. The essence of the attack lies in the fact that if PHP applications are running on the same server, then there is a high probability that, knowing the session ID, the attacker will be able to work with session data created in the attacked application. Poisoning is possible if the attacked application has an error that allows executing arbitrary code, and if the web application runs on the server along with applications from other hosting users.

The purpose of this attack is to gain access to read/write session values. If successful, an attacker will be able to read and/or falsify any value stored in the session. Poisoning is used to obtain the personal data of other users, as well as to modify one's own session, impersonate another and/or increase privileges.

Here is the simplest example of this attack:

$var = $_GET["something"];

$_SESSION["$var"] = $var2;

Authentication using forms.

When a client visits the page and enters a username and password, his credentials are transmitted to the server. If authentication is successful, the server generates a session ticket for this user, and for all subsequent requests to the server, this ticket is already used, the data of which is stored in a cookie. By default, the ticket's lifetime is 30 minutes. At the end of this time, the ticket can be automatically renewed. If there were no more requests within a certain time interval, the server sends a message to the client with a suggestion to "forget" this ticket, as a result of which the browser deletes this cookie, and the user must re-enter the credentials to log in.

It would seem that everything is quite logical and correct. But the client (or rather, the attacker) can periodically ask the server to renew its ticket, in fact, an unlimited number of times. In other words, the server has no control over how many times the ticket has been renewed. And an attacker can simply ignore the offer received from the server to "forget" his ticket and continue to renew it further.

Thus, if an attacker was able to steal the ticket cookie, he will be able to use the user session.

Cross Site Request Forgery.

The good old CSRF is also relevant for .NET. Recall that CSRF is a type of attack on website visitors that exploits the shortcomings of the HTTP protocol. If a victim visits a website created by an attacker, a request is secretly sent on her behalf to another server (for example, to a payment system server) that performs some kind of malicious operation (for example, transferring money to the attacker's account).

To carry out this attack, several conditions must be met. First, the victim must be authenticated on the server where the request is being made. Also, this request should not require any

user confirmation, which cannot be automated, that is, which cannot be forged by an attacking script.

As an example, consider a situation where a user logs in using authentication based on the very forms we discussed earlier. The server performs user authentication and issues a response that includes the user's ticket in a cookie. At the same time, the bank's website trusts any request it receives with a valid ticket in the cookie. Next, the user visits another site without forcibly ending the session on the bank's website, www.hacker.com , which contains an HTML form in which the following data is hidden in the form:

</form>

Please note that the form will send the data to the bank's website. This is the "cross-site" part of CSRF. Then, under some pretext, the user is asked to click a button that will secretly send the form data. When submitting the form, the browser will automatically send a cookie ticket for the requested domain, because the user is still formally logged in to the bank's website. As a result, the request will be executed on the bank's website. It is worth noting that using HTTPS does not prevent CSRF attacks. A malicious site can send a request just as easily as an insecure request.

Such attacks are made possible by the fact that cookies issued by the application are stored in the browser, these cookies contain, among other things, the session tickets of verified users, and finally the browser sends all domain-related cookies to the web application, regardless of how the request to the application was created in the browser.

Oleg Petukhov, lawyer in the field of international law and personal data protection, information security specialist security, protection of information and personal data.

Telegram channel: https://t.me/protectioninformation

Telegram Group: https://t.me/informationprotection1

Website: https://legascom.ru

Email: online@legascom.ru

#informationprotection #informationsecurity

Angriffe auf das Web durch Sitzungsmanagement.

Angriffe auf Webanwendungen über das Sitzungsmanagementsystem.

Ein weiterer Schwachpunkt sind Webanwendungen. Natürlich wird die Entwicklung von Webportalen für Unternehmen normalerweise von Webprogrammierern beauftragt, aber der Systemadministrator und insbesondere der IT-Spezialist sollten sich über die vorhandenen Sicherheitslücken im Web im Internet im Klaren sein. Außerdem beschäftigt sich der Systemadministrator in kleinen Unternehmen oft mit der Entwicklung und Unterstützung eines Unternehmensportals. Die folgenden Informationen werden also für viele nützlich sein.

Moderne Webportale werden hauptsächlich von Apache als Webserver verwendet. Es gibt natürlich IIS (Internet Information Services), das unter Windows läuft, aber die meisten Hosts verwenden immer noch das FreeBSD/Linux+Apache-Paket. Das Webportal verwendet normalerweise MySQL oder PostgreeSQL, um die Daten zu speichern, mit denen das Webportal arbeitet. In hochbelasteten Industriesystemen kann Oracle verwendet werden.

Normalerweise wird PHP oder Perl als Skriptsprache verwendet. Es gibt auch hochrangige Tools zur Entwicklung von Portallösungen von Microsoft, aber in diesem Abschnitt werden wir sie aufgrund ihrer geringeren Prävalenz im Vergleich zu den kostenlosen FreeBSD, Apache, MySQL und PHP nicht behandeln.

Betrachten wir als praktisches Beispiel Angriffe auf eine PHP-Anwendung über ein Session-Management-System. Die Hauptgründe für die Möglichkeit dieser Angriffe sind die fehlende Überprüfung der Sitzungs-ID des Benutzers und die fehlende Überprüfung der in der Sitzung gespeicherten Daten.

Betrachten wir die möglichen Angriffe auf die Anwendung.

Session Hijacking (Session Hijacking).

Der Kern des Angriffs besteht darin, dass ein Angreifer eine Sitzungs-ID verwendet, die einem legitimen Benutzer gehört, um sich als Sitzungsbesitzer auszugeben. Sie können die Sitzungs-ID einer anderen Person herausfinden, indem Sie den Datenverkehr eines legitimen Benutzers abfangen, einen XSS-Angriff organisieren oder durch einen Brute-Force-Angriff durchführen.

Der allgemeine Algorithmus für den Angriff ist wie folgt:

1) der Angreifer sammelt Informationen über die IP-Adressen des Opfers und die Ressource, auf die Sie zugreifen möchten;

2) sie müssen dann warten, bis sich der Angegriffene mit der Zielressource verbindet;

3) als nächstes muss der Angreifer ARP relay ausführen;

4) wenn sich das Opfer mit der Zielressource verbunden hat und damit begonnen hat, sieht der Angreifer eine neue aktive Verbindung im Sniffer. Als nächstes führt der Angreifer einen TCP / IP-Desynchronisierungsangriff durch, der bereits zuvor beschrieben wurde. Die Verbindung des Opfers «fällt" ab, indem ein RST-Paket erzwungen wird;

5) als nächstes kann der Angreifer im Namen des Opfers und mit seinen Kontorechten arbeiten;

6) der Angreifer muss sich erneut mit der Zielressource verbinden, wobei er zu Recht davon ausgeht, dass ein Hardware-Verbindungsfehler aufgetreten ist. Ein Angreifer sendet ihm eine RST;

7) wenn der Hacker das System beendet hat, hört er auf, RST zu senden und deaktiviert ARP-relay;

8) der gehackte Benutzer kann wieder mit dem System arbeiten.

Wie aus der Beschreibung nicht schwer zu verstehen ist, muss ein solcher Angriff an einen einzelnen Switch angeschlossen werden, der der Angegriffene ist. Das heißt, sich tatsächlich im selben lokalen Netzwerk wie das Opfer zu befinden.

In einem einfacheren Fall kann ein Angreifer versuchen, die Sitzung eines anderen zu hacken, indem er Cookies spoofing.

Hier ist ein kleines Beispiel für einen ähnlichen Angriff in der Praxis.

Sie benötigen einen Sniffer wie Wireshark, einen Browser (z. B. Firefox) und einen Cookie-Editor (Sie können das Add-on für Firefox verwenden), um es zu implementieren.

Der angegriffene Benutzer verbindet sich mit dem Portal des sozialen Netzwerks.

Ein Einbrecher nimmt den Verkehr ab. Nach dem Abfangen des Datenverkehrs muss der Angreifer die vom Benutzer übermittelten Cookies finden. Sie können dies in Wireshark wie folgt tun. Drücken Sie Strg + F oder Edit - Find Packet. Im Feld By: müssen Sie String und Search In auswählen, die Option Packet details, und im Textfeld müssen Sie Set-Cookie angeben.

Wenn das gewünschte Paket gefunden wurde, müssen Sie mit der rechten Maustaste klicken und «Follow TCP Stream» auswählen. Als nächstes können Sie in diesem Thread ein Paket finden, das dem angegebenen ähnlich ist.

Dies ist das notwendige Cookie. Als nächstes öffnen Sie den Cookie-Editor (Tools - Cookie Editor). Klicken Sie dann auf Hinzufügen und geben Sie Folgendes ein:

Name: _twitter_sess

Content: copy paste the information from the TCP Stream (see the red box in the Session Cookie Found from TCP Stream picture)

Domain: .twitter.com

Path: /

Wenn die Implementierung erfolgreich ist, muss der Angreifer jetzt keine Anmeldeinformationen angeben, um sich bei der Site anzumelden, sondern einfach auf die Seite zugreifen.

Die folgenden Schritte werden kurz ausgeführt:

1) verkehr abfangen;

2) erkennen eines Pakets, das einen Set-Cookie enthält;

3) setzen eines Cookies im Add-on-Cookie-Editor;

4) zugriff auf die gewünschte Website.

Sitzungsfixierung (Session Fixation).

Um diesen Angriff auszuführen, benötigt ein Angreifer keine Sitzungs-ID einer anderen Person, es genügt, die Sitzungs-ID eines legitimen Benutzers festzulegen, der autorisiert wurde. Wie im vorherigen Fall wird eine Situation erstellt, in der ein Angreifer und ein legitimer Benutzer dieselbe Sitzungs-ID haben.

Session Fixation ist eine Angriffsmethode, die die Sitzungs-ID auf einen bestimmten Wert setzt. Abhängig von der Funktionalität der angegriffenen Site können viele verschiedene Methoden verwendet werden, um die Sitzungs-ID zu «commit». Die Benutzersitzungs-ID wird dann festgelegt, und der Angreifer wartet auf diejenigen, die sich anmelden. Sobald ein Benutzer dies tut, verwendet der Angreifer einen vordefinierten Sitzungs-ID-Wert, um seine Online-Identität mit allen sich daraus ergebenden Konsequenzen zu erhalten.

Es gibt zwei Arten von Sitzungsmanagementsystemen: «frei» und «streng». Der Sitzungstyp wird abhängig davon bestimmt, wie die Identitätswerte generiert werden. Der erste Systemtyp ermöglicht es Webbrowsern, eine beliebige ID anzugeben. Der zweite Systemtyp akzeptiert nur die Werte, die auf dem Server generiert wurden. Auf freien Systemen wird eine beliebige Session-ID überhaupt verarbeitet, ohne auf die Website zuzugreifen. Strenge Systeme erfordern, dass ein Angreifer eine «Trap-Sitzung» bedient und regelmäßig auf die Website zugreift, um Zeitüberschreitungen durch Inaktivität zu verhindern.

Ohne aktiven Sitzungsfixierungsschutz kann ein Angriff gegen jede Website durchgeführt werden, die Sitzungen verwendet, um die Identität der Benutzer zu identifizieren. Websites, die Sitzungs-IDs verwenden, verwenden normalerweise Cookies, URLs und ausgeblendete Formularfelder werden ebenfalls verwendet. Leider sind Cookie-basierte Sitzungen für Angriffe einfacher.

Im Gegensatz zum Stehlen von Sitzungs-IDs von Benutzern, die nach der Anmeldung auf einer Website ausgeführt werden, bietet das Fixieren einer Sitzung deutlich mehr Möglichkeiten für einen Angriff. Der aktive Teil des Angriffs erfolgt vor der Anmeldung der Benutzer.

Betrachten Sie ein Beispiel für das klassische Commit einer Benutzersitzung.

Es gibt drei Stufen der Fixierung:

1) installation;

2) fixieren;

3) eintritt.

Im ersten Schritt setzt ein Angreifer eine «Sitzungsfalle» auf die angegriffene Site und erhält diese Sitzungs-ID. Oder ein Angreifer, der angegriffen werden soll, kann eine zufällige Sitzungs-ID auswählen. In diesem Fall muss der von der Trap-Sitzung festgelegte Wert jedoch bei wiederholten Verbindungen mit der Website beibehalten werden (um «am Leben zu sein»).

Im nächsten Schritt legt der Angreifer dann den Wert der Trap-Sitzung in den Browser des Benutzers und erfasst die ID der Benutzersitzung. Und in der dritten Phase wartet der Angreifer, bis sich der Benutzer beim System der angegriffenen Site anmeldet. Sobald der Benutzer dies tut, wird der Wert der festen Sitzungs-ID verwendet, und ein Angreifer kann mit dem kompromittierten System beginnen.

Sie können eine der folgenden Methoden ausführen, um die Benutzersitzungs-ID zu erfassen:

ausstellen eines Cookies mithilfe eines Clientskripts;

gibt mithilfe eines Clientskripts einen neuen Sitzungs-ID-Wert im Cookie aus. Cross-Site-Programmierung an Schwachstellen des Website-Sicherheitssystems kann dazu verwendet werden, den aktuellen Cookie-Wert zu ändern.

http://example/<script>document.cookie="sessionid=1234;%20domain=.example.som";</script>.idc

Hier ist ein Beispiel für das Ausgeben eines Cookies mit einem META-Tag. Diese Methode ist besonders effektiv, wenn der Cross-Site-Programmierblocker verhindert, dass HTML-Skripte, aber keine META-Tags injiziert werden.

http://example/<meta%20http-equiv=Set-Cookie%20content="sessionid=1234;%20domain=.example.wels">.idc

Geben Sie einen Cookie aus, indem Sie den HTTP-Antwortheader verwenden.

Ein Angreifer ruft entweder auf der Zielwebsite oder auf einer seiner Subdomains dazu auf, ein Cookie mit einer Sitzungs-ID auszugeben. Dies kann auf verschiedene Arten erreicht werden:

hacking eines Webservers in einer Domäne (z. B. ein schlecht unterstützter Server);

infektion eines benutzerdefinierten DNS-Servers, praktisch mit dem Hinzufügen des Webservers eines Angreifers zur angegriffenen Domäne (diese Art von Angriffen wurde bereits in den DNS-Beiträgen beschrieben);

installieren eines bösartigen Webservers in der angegriffenen Domäne (z. B. auf einer Workstation in einer Windows2000-Domäne befinden sich alle Workstations ebenfalls in einer DNS-Domäne);

verwenden eines HTTP-Antwort-Split-Angriffs.

Es ist auch hier erwähnenswert, dass ein langer Session-Commit-Angriff durch die Ausgabe permanenter Cookies (z. B. mit einer Lebensdauer von 10 Jahren) ausgeführt werden kann, die die Session auch nach einem Neustart des Computers durch den Benutzer festhalten. Hier ist ein Beispiel:

http://example/<script>document.cookie="sessionid=1234;%20Expires=Friday,%201-Jan2017%2000:00:00%20GMT";</script>.idc

Session Poisoning (Session Poisoning).

Die Gefahr einer vergifteten Sitzung tritt auf, wenn ein Angreifer die Möglichkeit hat, sein PHP-Skript auf dem Server zu installieren, auf dem die angegriffene Anwendung ausgeführt wird. Das Wesen des Angriffs besteht darin, dass, wenn PHP-Anwendungen auf demselben Server ausgeführt werden, es wahrscheinlich ist, dass ein Angreifer, wenn er die Sitzungs-ID kennt, mit den Sitzungsdaten arbeiten kann, die in der angegriffenen Anwendung erstellt wurden. Eine Vergiftung ist möglich, wenn die angegriffene Anwendung einen Fehler aufweist, der die Ausführung beliebigen Codes ermöglicht, und wenn die Webanwendung zusammen mit den Anwendungen anderer Hosting-Benutzer auf dem Server ausgeführt wird.

Der Zweck dieses Angriffs besteht darin, auf lese-/schreibfähige Sitzungswerte zuzugreifen. Wenn dies erfolgreich ist, kann ein Angreifer jeden in der Sitzung gespeicherten Wert lesen und/oder fälschen. Vergiftungen werden verwendet, um persönliche Daten anderer Benutzer zu erhalten, ihre eigene Sitzung zu modifizieren, sich für einen anderen auszugeben und / oder Privilegien zu erhöhen.

Hier ist das einfachste Beispiel für diesen Angriff:

$var = $_GET["something"];

$_SESSION["$var"] = $var2;

Authentifizierung mit Formularen.

Wenn ein Client die Seite besucht und einen Benutzernamen und ein Passwort eingibt, werden seine Anmeldeinformationen an den Server übermittelt. Wenn die Authentifizierung erfolgreich abgeschlossen wurde, erstellt der Server ein Sitzungsticket für diesen Benutzer und verwendet bei allen nachfolgenden Zugriffen auf den Server bereits dieses Ticket, dessen Daten in einem Cookie gespeichert werden. Standardmäßig beträgt die Lebensdauer des Tickets 30 Minuten. Am Ende dieser Zeit kann das Ticket automatisch verlängert werden. Wenn es innerhalb eines bestimmten Zeitraums keine weiteren Zugriffe mehr gab, sendet der Server eine Nachricht an den Client, in der er aufgefordert wird, dieses Ticket zu vergessen, wodurch der Browser dieses Cookie löscht und der Benutzer seine Anmeldeinformationen erneut eingeben muss, um sich anzumelden.

Es scheint, dass alles ganz logisch und richtig ist. Aber der Kunde (oder vielmehr der Angreifer) kann den Server regelmäßig bitten, sein Ticket zu verlängern, im Wesentlichen eine unbegrenzte Anzahl von Malen. Das heißt, der Server hat keine Kontrolle darüber, wie oft das Ticket verlängert wurde. Und ein Angreifer kann das vom Server erhaltene Angebot, sein Ticket zu vergessen, einfach ignorieren und es weiter verlängern.

Wenn ein Angreifer also ein Ticket-Cookie stehlen konnte, kann er eine Benutzersitzung verwenden.

Cross Site Request Forgery.

Die gute alte CSRF ist auch für .NET relevant. Daran erinnern, dass CSRF eine Art von Angriffen auf Website-Besucher ist, die die Fehler des HTTP-Protokolls ausnutzen. Wenn ein Opfer eine von einem Angreifer erstellte Website besucht, wird heimlich eine Anfrage an einen anderen Server (z. B. einen Zahlungssystem-Server) gesendet, der eine bösartige Operation durchführt (z. B. eine Geldüberweisung auf das Konto des Angreifers).

Für diesen Angriff müssen mehrere Bedingungen erfüllt sein. Zuerst muss das Opfer auf dem Server authentifiziert werden, auf dem die Anfrage ausgeführt wird. Diese Anfrage sollte auch keine Anforderung erfordern

eine Bestätigung seitens des Benutzers, die nicht automatisiert werden kann, d. H. Die nicht durch ein angreifendes Skript manipuliert werden kann.

Betrachten wir als Beispiel eine Situation, in der sich ein Benutzer mit der Authentifizierung auf der Grundlage der Formulare anmeldet, über die wir etwas früher gesprochen haben. Der Server authentifiziert den Benutzer und gibt eine Antwort aus, die das Ticket des Benutzers im Cookie enthält. Dabei vertraut die Website der Bank auf jede Anfrage, die sie mit einem gültigen Cookie-Ticket erhält. Als nächstes besucht der Benutzer, ohne die Sitzung auf der Website der Bank zwangsweise zu beenden, eine andere Website, www.hacker.com enthält ein HTML-Formular, in dem das Senden der folgenden Daten im Formular gesperrt ist:

</form>

Bitte beachten Sie, dass das Formular die Daten an die Website der Bank sendet. Dies ist der »standortübergreifende" Teil von CSRF. Als nächstes wird der Benutzer unter irgendeinem Vorwand aufgefordert, auf eine Schaltfläche zu klicken, die die Formulardaten heimlich sendet. Beim Senden des Formulars sendet der Browser automatisch ein Cookie für die angeforderte Domain, da der Benutzer formal noch auf der Website der Bank eingeloggt ist. Als Ergebnis wird die Anfrage auf der Website der Bank ausgeführt. Es ist erwähnenswert, dass die Verwendung von HTTPS CSRF-Angriffe nicht verhindert. Eine in böser Absicht erstellte Website kann eine Anfrage genauso einfach senden wie eine unsichere Anfrage.

Diese Angriffe werden dadurch möglich, dass die von der Anwendung ausgestellten Cookies im Browser gespeichert werden, diese Cookies einschließlich Sitzungstickets von authentifizierten Benutzern enthalten und der Browser schließlich alle mit der Domäne verknüpften Cookies an die Webanwendung sendet, unabhängig davon, wie die Anforderung an die Anwendung im Browser erstellt wurde.

Oleg Petukhov, Rechtsanwalt im Bereich des Völkerrechts und des Schutzes personenbezogener Daten, Spezialist für Informationstechnik sicherheit, Schutz von Informationen und persönlichen Daten.

Telegramm-Kanal: https://t.me/datenschutzmit

Die Gruppe im Telegramm: https://t.me/datenschutzmit1

Website: https://legascom.ru

E-Mail: online@legascom.ru

#informationssicherheit #informationssicherheit

Attaques sur le Web via la gestion de session.

Attaques sur les applications Web via le système de gestion de session.

Les applications Web sont une autre vulnérabilité. Bien sûr, le développement de portails Web d'entreprise est généralement confié à des programmeurs Web professionnels, mais un administrateur système et encore moins un spécialiste de l'IB doivent avoir une idée des vulnérabilités existantes dans les applications Web. En outre, dans les petites entreprises, sisadmin est souvent engagé dans le développement et la maintenance d'un portail d'entreprise. Donc, les informations ci-dessous seront utiles à beaucoup.

Les portails Web modernes utilisent principalement Apache comme serveur Web. Il existe bien sûr IIS (Internet Information Services) fonctionnant sous Windows, mais la plupart des hébergeurs utilisent toujours le bundle FreeBSD/Linux+Apache. MySQL Ou PostgreeSQL sont généralement utilisés pour stocker les données avec lesquelles le portail Web fonctionne. Oracle peut être utilisé dans les systèmes industriels à forte charge.

PHP ou Perl est généralement utilisé comme langage de script. Il existe également des outils de développement de portail de haut niveau de Microsoft, mais dans cette section, nous ne les aborderons pas en raison de leur faible prévalence par rapport aux FreeBSD, Apache, MySQL, PHP.

À titre d'exemple pratique, considérons les attaques sur une application PHP via un système de gestion de session. Les principales raisons de la possibilité de ces attaques sont l'absence de validation de l'ID de session de l'utilisateur et l'absence de validation des données stockées dans la session.

Nous examinerons les variantes possibles des attaques sur l'application.

Vol de session (session Hijacking).

L'essence de l'attaque est l'utilisation par un attaquant d'un ID de session appartenant à un utilisateur légitime pour se faire passer pour le propriétaire de la session. Vous pouvez trouver l'ID de la session de quelqu'un d'autre en interceptant le trafic d'un utilisateur légitime, en organisant une attaque XSS ou en effectuant des recherches.

L'algorithme général de mise en œuvre de l'attaque est le suivant:

1) l'attaquant recueille des informations sur les adresses IP de la victime et la ressource à laquelle vous devez accéder;

2) ensuite, vous devez attendre que l'attaquant se connecte à la ressource cible;

3) ensuite, l'attaquant doit exécuter ARP relay;

4) lorsque la victime s'est connectée à la ressource cible et a commencé à travailler avec elle, l'attaquant verra une nouvelle connexion active dans le renifleur. Ensuite, le pirate effectue une attaque par désynchronisation TCP / IP, qui a déjà été décrite précédemment. La connexion de la victime «tombe» par l'envoi forcé d'un paquet RST;

5) en outre, l'attaquant peut travailler pour le compte de la victime et avec ses droits d'identification;

6) l'attaquant est obligé de se reconnecter à la ressource cible, croyant à juste titre qu'il y a eu une défaillance matérielle de la connexion. L'attaquant lui envoie RST;

7) lorsque le pirate a fini de travailler avec le système, il arrête d'envoyer RST et désactive ARP-relay;

8) l'utilisateur piraté peut à nouveau travailler avec le système.

Comme il n'est pas difficile de comprendre à partir de la Description, pour mettre en œuvre une telle attaque, il est nécessaire d'être connecté au même commutateur que celui attaqué. C'est-à-dire être dans le même réseau local que la victime.

Dans un cas plus simple, un attaquant peut essayer de pirater la session de quelqu'un d'autre en utilisant l'usurpation de cookies.

Voici un petit exemple d'une attaque similaire dans la pratique.

Pour l'implémenter, vous avez besoin d'un renifleur, par exemple Wireshark, d'un navigateur (par exemple Firefox) et d'un éditeur de Cookies (vous pouvez utiliser add-on pour Firefox).

L'utilisateur attaqué se connecte au portail du réseau social.

Le pirate renifle le trafic. Une fois le trafic intercepté, l'attaquant doit trouver les cookies transmis par l'utilisateur. Vous pouvez le faire dans Wireshark comme suit. Appuyez sur Ctrl + F ou sur Edit-Find Packet. Dans le champ By:, vous devez sélectionner String et Search In, l'option Packet details, dans le champ de texte, vous devez spécifier Set-Cookie.

Lorsque le paquet souhaité est trouvé, vous devez cliquer avec le bouton droit de la souris et sélectionner «suivre le flux TCP». Ensuite, dans ce fil, vous pouvez trouver un paquet similaire à celui ci.

C'est le cookie nécessaire. Ensuite, vous devez ouvrir l'éditeur de Cookies (Tools-Cookie Editor). Puis cliquez sur Add et spécifiez ce qui suit:

Name: _twitter_sess

Content: copy paste the information from the TCP Stream (see the red box in the Session Cookie Found from TCP Stream picture)

Domain: .twitter.com

Path: /

Dans le cas d'une implémentation réussie, l'attaquant n'a plus besoin de fournir d'informations d'identification pour se connecter au site, il suffit d'aller à la page.

Les actions suivantes sont brièvement effectuées:

1) interception du trafic;

2) détecter un paquet contenant un Set-Cookie;

3) réglage des Cookies dans l'éditeur de Cookies add-on;

4) accédez au site souhaité.

Fixation de session.

Pour mener à bien cette attaque, l'attaquant n'a pas besoin de l'ID de la session de quelqu'un d'autre, il suffit de définir l'ID de sa session à un utilisateur légitime authentifié. Comme dans le cas précédent, une situation est créée lorsque l'attaquant et l'utilisateur légitime partagent le même ID de session.

La fixation de session est une méthode d'attaque qui force l'ID de session à une valeur spécifique. Selon la fonctionnalité du site attaqué, de nombreuses méthodes différentes peuvent être appliquées pour «valider» l'ID de session. Ensuite, l'ID de session de l'utilisateur est capturé et l'attaquant attend ceux qui se connecteront. Une fois que l'utilisateur a fait cela, l'attaquant utilise une valeur d'identifiant de session prédéfinie pour obtenir son identité en ligne avec toutes les conséquences qui en découlent.

Il existe deux types de systèmes de gestion de session: «libre» et «strict». Le type de session est déterminé en fonction de la façon dont les valeurs d'ID sont générées. Le premier type de système permet aux navigateurs Web de spécifier n'importe quel identifiant. Le deuxième type de système accepte uniquement les valeurs générées sur le serveur. Dans les systèmes libres, un ID de session arbitraire est traité sans accès au site Web. Les systèmes stricts exigent qu'un attaquant gère une «session piège» avec un accès périodique au site Web pour éviter les délais d'inactivité.

Contrairement au vol des identifiants de session des utilisateurs effectués après leur connexion à un site Web, la fixation d'une session offre beaucoup plus de possibilités d'attaque. La partie active de l'attaque se fait avant que les utilisateurs se connectent.

Prenons l'exemple de la validation classique d'une session utilisateur.

Il existe trois étapes de fixation:

1) installation;

2) fixation;

3) occurrence.

Dans la première étape, l'attaquant installe une «session piège» sur le site attaqué et obtient cet ID de session. Ou l'attaquant à attaquer pourrait choisir un ID de session aléatoire. Mais dans ce cas, la valeur définie par le piège de session doit être maintenue (pour «être en vie») avec des connexions répétées au site Web.

Ensuite, à l'étape suivante, l'attaquant place la valeur de la session de capture dans le navigateur de l'utilisateur et capture l'ID de la session de l'utilisateur. Et dans la troisième étape, l'attaquant attend que l'utilisateur se connecte au site attaqué. Une fois que l'utilisateur fait cela, la valeur de l'ID de session fixe sera utilisée et l'attaquant pourrait commencer à travailler avec le système compromis.

Vous pouvez effectuer l'une des méthodes suivantes pour valider l'ID de session utilisateur:

émission d'un cookie à l'aide d'un script client;

émettre une nouvelle valeur d'ID de session dans le cookie à l'aide d'un script client. La programmation intersite dans les points faibles du système de protection du site Web peut être utilisée pour modifier la valeur actuelle du cookie.

http://example/<script>document.cookie="sessionid=1234;%20domain=.example.Som";< / script>.idc

Voici un exemple d'émission d'un cookie en utilisant une balise META. Cette méthode est efficace, en particulier lorsque le bloqueur de programmation intersite empêche l'injection de balises de script HTML, mais pas de balises META.

http://example/<meta%20http-equiv=Set-Cookie%20content="sessionid=1234;%20domain=.example.Som">.idc

Émission d'un cookie à l'aide d'un en-tête de réponse HTTP.

L'attaquant déclenche soit sur le site Web cible, soit sur l'un de ses sous-domaines, l'émission d'un cookie avec un identifiant de session. Cela peut être fait de différentes manières:

piratage d'un serveur Web dans un domaine (par exemple, un serveur mal pris en charge);

infecter un serveur DNS personnalisé, pratiquement avec l'ajout du serveur Web de l'attaquant au domaine attaqué (ce type d'attaque a déjà été décrit un peu dans les messages consacrés au DNS);

installation d'un serveur Web malveillant dans le domaine attaqué (par exemple, sur un poste de travail dans le domaine Windows2000, tous les postes de travail sont également dans le domaine DNS);

l'utilisation d'une attaque de partitionnement de la réponse HTTP.

Il convient également de noter ici qu'une attaque de validation de session prolongée peut être effectuée par l'émission de cookies persistants (par exemple, avec une durée de vie de 10 ans) qui maintiendront la validation de session même après le redémarrage de l'ordinateur de l'utilisateur. Voici un exemple:

http://example/<script>document.cookie="sessionid=1234;%20Expires=Friday,%201-Jan2017%2000:00:00%20GMT";</script>.idc

Empoisonnement de session (session Poisoning).

La menace d'une session empoisonnée se produit si un attaquant a la possibilité d'installer son script PHP sur le serveur où l'application attaquée est exécutée. L'essence de l'attaque est que si les applications PHP sont exécutées sur le même serveur, il y a de fortes chances que, connaissant l'ID de session, l'attaquant puisse travailler avec les données de session créées dans l'application attaquée. L'empoisonnement est possible si l'application attaquée a un bogue permettant l'exécution de code arbitraire et si l'application Web s'exécute sur le serveur avec les applications d'autres utilisateurs de l'hébergement.

Le but de cette attaque est d'accéder aux valeurs de session en lecture/écriture. En cas de succès, l'attaquant pourrait lire et/ou falsifier toute valeur stockée dans la session. Les empoisonnements sont utilisés pour obtenir des données personnelles d'autres utilisateurs, ainsi que pour modifier leur propre session, se faire passer pour un autre et/ou augmenter les privilèges.

Voici l'exemple le plus simple de cette attaque:

$var = $_GET["something"];

$_SESSION["$var"] = $var2;

Authentification par formulaires.

Lorsqu'un client accède à une page et entre un identifiant et un mot de passe, ses informations d'identification sont transmises au serveur. Dans le cas où l'authentification réussit, le serveur génère un ticket de session pour cet utilisateur et tous les appels ultérieurs au serveur utilisent déjà ce ticket, dont les données sont stockées dans le cookie. Par défaut, la durée de vie du billet est de 30 minutes. À la fin de cette période, le billet peut être renouvelé automatiquement. Dans le cas où il n'y avait plus d'accès pendant un certain intervalle de temps, le serveur envoie au client un message lui demandant d'oublier ce ticket, ce qui entraîne la suppression du cookie par le navigateur et l'utilisateur doit entrer de nouveau les informations d'identification pour se connecter.

Il semblerait que tout soit tout à fait logique et correct. Mais le client (ou plutôt l'attaquant) peut demander périodiquement au serveur de renouveler son ticket, essentiellement un nombre illimité de fois. Autrement dit, le serveur ne contrôle pas le nombre de fois que le ticket a été renouvelé. Et l'attaquant peut simplement ignorer l'offre reçue du serveur «oublier» son ticket et continuer à le renouveler.

De cette façon, si un attaquant pouvait voler un cookie avec un ticket, il pourrait utiliser la session de l'utilisateur.

Cross Site Request Forgery.

Le bon vieux CSRF est également pertinent pour .NET. Rappelons que CSRF est une sorte d'attaque contre les visiteurs de sites Web qui utilise les failles du protocole HTTP. Si la victime accède à un site créé par un attaquant, une demande est secrètement envoyée en son nom à un autre serveur (par exemple, un serveur de système de paiement) effectuant une opération malveillante (par exemple, le transfert d'argent sur le compte de l'attaquant).

une confirmation de la part de l'utilisateur qui ne peut pas être automatisée, c'est-à-dire qui ne peut pas être falsifiée par un script attaquant.

À titre d'exemple, considérons une situation dans laquelle un utilisateur se connecte à l'aide d'une authentification basée sur les mêmes formulaires dont nous avons parlé un peu plus tôt. Le serveur authentifie l'utilisateur et émet une réponse qui inclut le ticket de l'utilisateur dans le cookie. Ce faisant, le site de la banque fait confiance à toute demande qu'elle reçoit avec un ticket de cookie valide. Ensuite, l'utilisateur, sans terminer la session de force sur le site de la banque, visite un autre site, www.hacker.com qui contient un formulaire HTML dans lequel l'envoi sous la forme suivante est masqué:

</form>

Veuillez noter que le formulaire enverra les données sur le site de la banque. C'est la partie» intersite " de CSRF. Ensuite, sous quelque prétexte que ce soit, l'utilisateur est invité à cliquer sur un bouton qui enverra secrètement les données du formulaire. Lors de l'envoi du formulaire, le navigateur enverra automatiquement un ticket dans le cookie pour le domaine demandé, car l'utilisateur est officiellement encore bloqué sur le site de la banque. En conséquence, la demande sera effectuée sur le site Web de la banque. Il convient de noter que l'utilisation de HTTPS n'empêche pas les attaques CSRF. Un site malveillant peut envoyer une requête aussi facilement qu'une requête non sécurisée.

Ces attaques sont rendues possibles par le fait que le navigateur stocke les cookies émis par l'application, ces cookies contiennent notamment les tickets de session des utilisateurs authentifiés, et enfin le navigateur envoie à l'application Web tous les cookies associés au domaine, quelle que soit la façon dont la demande à l'application a été créée dans le navigateur.

Petukhov Oleg, avocat en droit international et protection des données personnelles, spécialiste de l'information sécurité, protection de l'information et des données personnelles.

Telegram Channel: https://t.me/protecciondelainformacion

Groupe au Télégramme: https://t.me/securiteinformatique2

Site: https://legascom.ru

E-mail: online@legascom.ru

#sécuritéinformations #informationsécurité

Attaques sur le Web par la gestion de session.

Attaques sur les applications Web par le biais du système de gestion de session.

Les applications Web sont une autre vulnérabilité. Bien sûr, le développement de portails Web d'entreprise est généralement confié à des programmeurs Web professionnels, mais un administrateur système et encore moins un spécialiste de l'IB doivent avoir une idée des vulnérabilités existantes dans les applications Web. De plus, dans les petites entreprises, sisadmin est souvent engagé dans le développement et la maintenance d'un portail d'entreprise. Donc, les informations ci-dessous seront utiles à beaucoup.

Les portails Web modernes utilisent principalement Apache comme serveur Web. Il existe bien sûr IIS (Internet Information Services) fonctionnant sous Windows, mais la plupart des hébergeurs utilisent toujours le bundle FreeBSD/Linux+Apache. MySQL ou PostgreeSQL sont généralement utilisés pour stocker les données avec lesquelles le portail Web fonctionne. Oracle peut être utilisé dans les systèmes industriels à forte charge.

Nous examinerons les variantes possibles des attaques sur l'application.

Vol de session (session Hijacking).

L'essence de l'attaque est l'utilisation par un attaquant d'un ID de session appartenant à un utilisateur légitime pour se faire passer pour le propriétaire de la session. Vous pouvez trouver l'ID de session de quelqu'un d'autre en interceptant le trafic d'un utilisateur légitime, en organisant une attaque XSS ou en effectuant des recherches.

L'algorithme général de mise en œuvre de l'attaque est le suivant :

1) l'attaquant recueille des renseignements sur les adresses IP de la victime et la ressource à laquelle vous devez accéder;

2) ensuite, vous devez attendre que l'attaquant se connecte à la ressource cible;

3) ensuite, l'attaquant doit exécuter ARP relay;

5) de plus, l’agresseur peut travailler pour le compte de la victime et avec ses droits d’identification;

6) l'attaquant est obligé de se reconnecter à la ressource cible, croyant à juste titre qu'il y a eu une défaillance matérielle de la connexion. L'attaquant lui envoie RST;

7) lorsque le pirate a terminé de travailler avec le système, il cesse d'envoyer RST et désactive ARP-relay;

8) l'utilisateur piraté peut à nouveau travailler avec le système. Comme il n'est pas difficile de comprendre à partir de la Description, pour mettre en œuvre une telle attaque, il faut être connecté au même commutateur que celui attaqué. C'est-à-dire être dans le même réseau local que la victime.

Dans un cas plus simple, un attaquant peut essayer de pirater la session de quelqu'un d'autre en utilisant l'usurpation de cookies. Voici un petit exemple d'une attaque semblable en pratique.

Pour l'implémenter, vous avez besoin d'un renifleur, par exemple Wireshark, d'un navigateur (par exemple Firefox) et d'un éditeur de témoins (vous pouvez utiliser add-on pour Firefox).

L'utilisateur attaqué se connecte au portail du réseau social.

Le pirate renifle le trafic. Une fois le trafic intercepté, l'attaquant doit trouver les témoins transmis par l'utilisateur. Vous pouvez le faire dans Wireshark comme suit. Appuyez sur Ctrl + F ou sur Edit-Find Packet. Dans le champ By:, vous devez sélectionner String et Search In, l'option Packet details, dans le champ de texte, vous devez spécifier Set-Cookie.

C'est le biscuit nécessaire. Ensuite, vous devez ouvrir l'éditeur de témoins (éditeur de cookies de l'outil). Puis cliquez sur Ajouter et précisez ce qui suit:

Nom : _twitter_sess

Contenu : copiez les informations provenant du flux TCP (voir la boîte rouge dans le cookie de session provenant de l'image de diffusion TCP)

Domaine : .twitter.com

Path: /

Dans le cas d'une implémentation réussie, l'attaquant n'a plus besoin de fournir d'informations d'identification pour se connecter au site, il suffit d'aller à la page.

Les actions suivantes sont brièvement faites :

1) interception du trafic;

2) détecter un paquet contenant un Set-Cookie;

3) Réglage des témoins dans l'éditeur de témoins à module complémentaire;

4) allez sur le site souhaité.

Fixation de session.

Pour mener à bien cette attaque, l'attaquant n'a pas besoin de l'ID de session de quelqu'un d'autre, il suffit de définir l'identifiant de sa session à un utilisateur légitime authentifié. Comme dans le cas précédent, une situation est créée lorsque l'attaquant et l'utilisateur légitime partagent le même ID de session.

La fixation de session est une méthode d'attaque qui force l'ID de session à une valeur spécifique. Selon la fonctionnalité du site attaqué, de nombreuses méthodes différentes peuvent être appliquées pour « valider » l'ID de session. Ensuite, l'ID de session de l'utilisateur est capturé et l'attaquant attend ceux qui se connecteront. Une fois que l'utilisateur a fait cela, l'attaquant utilise une valeur d'identifiant de session prédéfinie pour obtenir son identité en ligne avec toutes les conséquences qui en découlent.

Il existe deux types de systèmes de gestion de session: «libre» et «strict». Le type de session est déterminé en fonction de la façon dont les valeurs d'ID sont générées. Le premier type de système permet aux navigateurs Web de spécifier n'importe quel identifiant. Le deuxième type de système accepte seulement les valeurs générées sur le serveur. Dans les systèmes libres, un ID de session arbitraire est traité sans accès au site Web. Les systèmes stricts exigent qu'un attaquant gère une « session piège » avec un accès périodique au site Web pour éviter les délais d'inactivité.

Sans protection active contre la validation de session, une attaque peut être lancée contre tout site Web utilisant des sessions pour authentifier les utilisateurs. Les sites Web qui utilisent des identifiants de session utilisent généralement des témoins, ainsi que des URL et des champs de formulaire masqués. Malheureusement, les sessions basées sur des témoins sont plus faciles pour les attaques. Contrairement au vol des identifiants de session des utilisateurs effectués après leur connexion à un site Web, la fixation d'une session offre beaucoup plus de possibilités d'attaque. La partie active de l'attaque se fait avant que les utilisateurs se connectent.

Prenons l'exemple de la validation classique d'une session utilisateur.

Il y a trois étapes de fixation :

1) installation;

2) fixation;

3) occurrence.

Dans la première étape, l'attaquant installe une « session piège » sur le site attaqué et obtient cet ID de session. Ou l'attaquant à attaquer pourrait choisir un ID de session aléatoire. Mais dans ce cas, la valeur définie par le piège de session doit être maintenue (pour « être en vie ») avec des connexions répétées au site Web.

Ensuite, à l'étape suivante, l'attaquant place la valeur de la session de capture dans le navigateur de l'utilisateur et capture l'ID de la session de l'utilisateur. Et à la troisième étape, l'attaquant attend que l'utilisateur se connecte au site attaqué. Une fois que l'utilisateur fait cela, la valeur de l'ID de session fixe sera utilisée et l'attaquant pourrait commencer à travailler avec le système compromis.

Vous pouvez effectuer l'une des méthodes suivantes pour valider l'ID de session utilisateur:

émission d'un témoin à l'aide d'un script client;

émettre une nouvelle valeur d'ID de session dans le témoin à l'aide d'un script client. La programmation intersite dans les points faibles du système de protection du site Web peut être utilisée pour modifier la valeur actuelle du cookie.

http://example/<script>document.cookie="sessionid=1234;%20domain=.example.Som";< / script>.idc

Voici un exemple d'émission d'un biscuit en utilisant une balise META. Cette méthode est efficace, en particulier lorsque le bloqueur de programmation intersite empêche l'injection de balises de script HTML, mais pas de balises META.

http://example/<meta%20http-equiv=Set-Cookie%20content="sessionid=1234;%20domain=.example.Som">.idc Émission d'un témoin à l'aide d'un en-tête de réponse HTTP.

L'attaquant déclenche soit sur le site Web cible, soit sur l'un de ses sous-domaines, l'émission d'un cookie avec un identifiant de session. Cela peut être fait de différentes façons:

piratage d'un serveur Web dans un domaine (par exemple, un serveur mal pris en charge);

installation d'un serveur Web malveillant dans le domaine attaqué (par exemple, sur un poste de travail dans le domaine Windows2000, tous les postes de travail sont également dans le domaine DNS);

l'utilisation d'une attaque de partitionnement de la réponse HTTP.

Il convient également de noter ici qu'une attaque de validation de session prolongée peut être effectuée par l'émission de témoins persistants (par exemple, avec une durée de vie de 10 ans) qui maintiendront la validation de session même après le redémarrage de l'ordinateur de l'utilisateur. Voici un exemple:

http://example/<script>document.cookie="sessionid=1234;%20Expires=Friday,%201-Jan2017%2000:00:00%20GMT";</script>.idc

Empoisonnement de session (session Poisoning).

Le but de cette attaque est d'accéder aux valeurs de session en lecture/écriture. Si réussi, l'attaquant pourrait lire et/ou falsifier toute valeur stockée dans la session. Les empoisonnements sont utilisés pour obtenir des données personnelles d'autres utilisateurs, ainsi que pour modifier leur propre session, se faire passer pour un autre et/ou augmenter les privilèges.

Voici l'exemple le plus simple de cette attaque :

$var = $_GET["quelque chose"];

$_SESSION["$var"] = $var2;

Authentification par formulaires.

Lorsqu'un client accède à une page et entre un identifiant et un mot de passe, ses informations d'identification sont transmises au serveur. Dans le cas où l'authentification réussit, le serveur génère un ticket de session pour cet utilisateur et tous les appels ultérieurs au serveur utilisent déjà ce ticket, dont les données sont stockées dans le cookie. Par défaut, la durée de vie du billet est de 30 minutes. À la fin de cette période, le billet peut être renouvelé automatiquement. Dans le cas où il n'y avait plus d'accès pendant un certain laps de temps, le serveur envoie au client un message lui demandant d'oublier ce billet, ce qui entraîne la suppression du témoin par le navigateur et l'utilisateur doit saisir de nouveau les informations d'identification pour se connecter.

Il semblerait que tout soit tout à fait logique et correct. Mais le client (ou plutôt l'attaquant) peut demander périodiquement au serveur de renouveler son billet, essentiellement un nombre illimité de fois. Autrement dit, le serveur ne contrôle pas le nombre de fois que le billet a été renouvelé. Et l'attaquant peut simplement ignorer l'offre reçue du serveur «oublier» son billet et continuer à le renouveler.

De cette façon, si un attaquant pouvait voler un biscuit avec un billet, il pourrait utiliser la session de l'utilisateur. Cross Site Request Forgery.

Le bon vieux CSRF est aussi pertinent pour .NET. Rappelons que CSRF est une sorte d'attaque contre les visiteurs de sites Web qui utilise les failles du protocole HTTP. Si la victime accède à un site créé par un attaquant, une demande est secrètement envoyée en son nom à un autre serveur (par exemple, un serveur de système de paiement) effectuant une opération malveillante (par exemple, le transfert d'argent sur le compte de l'attaquant).

Plusieurs conditions doivent être remplies pour mener à bien cette attaque. Tout d'abord, la victime doit être authentifiée sur le serveur sur lequel la requête est exécutée. De plus, cette demande ne devrait pas nécessiter une confirmation de la part de l'utilisateur qui ne peut pas être automatisée, c'est-à-dire qui ne peut pas être falsifiée par un script attaquant.

À titre d'exemple, considérons une situation dans laquelle un utilisateur se connecte à l'aide d'une authentification basée sur les mêmes formulaires dont nous avons parlé un peu plus tôt. Le serveur authentifie l'utilisateur et émet une réponse qui inclut le billet de l'utilisateur dans le cookie. En faisant cela, le site de la banque fait confiance à toute demande qu'elle reçoit avec un billet de biscuit valide. Ensuite, l'utilisateur, sans terminer la session de force sur le site de la banque, visite un autre site, www.hacker.com qui contient un formulaire HTML dans lequel l'envoi sous la forme suivante est masqué :

</form>

Veuillez noter que le formulaire enverra les données sur le site Web de la banque. C'est la partie « intersite » de CSRF. Ensuite, sous quelque prétexte que ce soit, l'utilisateur est invité à cliquer sur un bouton qui enverra secrètement les données du formulaire. Lors de l'envoi du formulaire, le navigateur enverra automatiquement un billet dans le cookie pour le domaine demandé, car l'utilisateur est officiellement encore bloqué sur le site de la banque. Par conséquent, la demande sera effectuée sur le site Web de la banque. Il convient de noter que l'utilisation de HTTPS n'empêche pas les attaques CSRF. Un site malveillant peut envoyer une requête aussi facilement qu'une requête non sécurisée.

Ces attaques sont rendues possibles par le fait que le navigateur stocke les témoins émis par l'application, ces témoins contiennent notamment les tickets de session des utilisateurs authentifiés, et enfin le navigateur envoie à l'application Web tous les témoins associés au domaine, quelle que soit la façon dont la demande à l'application a été créée dans le navigateur.

Petukhov Oleg, avocat en droit international et protection des renseignements personnels, spécialiste de l'information sécurité, protection de l'information et des données personnelles.

Canal Telegram: https://t.me/protecciondelainformacion

Groupe au Télégramme: https://t.me/securiteinformatique2

Site: https://legascom.ru

Courriel: online@legascom.ru

#sécuritéinformations #informationsécurité

Ataques a la web a través de la gestión de sesiones.

Ataques a aplicaciones web a través del sistema de gestión de sesiones.

Otro punto vulnerable son las aplicaciones web. Por supuesto, el desarrollo de portales web corporativos generalmente se confía a los programadores web profesionales, pero el administrador del sistema y, más aún, el especialista en seguridad informática deben tener una idea de las vulnerabilidades existentes en la web en las ubicaciones. Además, en las pequeñas empresas, el administrador de sistemas a menudo se dedica al desarrollo y soporte de un portal corporativo. Así que la siguiente información será útil para muchos.

Los portales web modernos utilizan principalmente Apache como servidor web. Hay, por supuesto, IIS (Internet Information Services) que se ejecuta en Windows, pero la mayoría de los servicios de alojamiento aún usan el paquete FreeBSD/Linux+Apache. Para almacenar los datos con los que se ejecuta un portal web, generalmente se usa MySQL o PostgreeSQL. Oracle se puede utilizar en sistemas industriales de alta carga.

PHP o Perl se usan comúnmente como lenguaje de scripting. También hay herramientas de desarrollo de portal de alto nivel de Microsoft, pero en esta sección no las abordaremos debido a su menor prevalencia, en comparación con FreeBSD, Apache, MySQL y PHP gratuitos.

Como ejemplo práctico, considere los ataques a una aplicación PHP a través de un sistema de gestión de sesiones. Las principales razones de la posibilidad de estos ataques son la falta de validación del id de sesión del usuario y la falta de validación de los datos almacenados en la sesión.

Considere las posibles opciones de ataque a la aplicación.

Robo de sesión (session Hijacking).

La esencia del ataque es el uso por parte de un atacante de un identificador de sesión que pertenece a un usuario legítimo para hacerse pasar por el propietario de la sesión. Puede averiguar el id de la sesión de otra persona interceptando el tráfico de un usuario legítimo, organizando un ataque XSS o mediante la fuerza bruta.

El algoritmo general para realizar un ataque es el siguiente:

1) el atacante recopila información sobre las direcciones IP de la víctima y el recurso al que debe acceder;

2) luego debe esperar a que el atacante se conecte al recurso objetivo;

3) a continuación, el atacante debe ejecutar ARP relay;

4) cuando la víctima se conectó al recurso objetivo y comenzó a trabajar con él, el atacante verá una nueva conexión activa en el sniffer. A continuación, el atacante realiza un ataque de desincronización TCP / IP, que ya se describió anteriormente. La conexión de la víctima se "cae" mediante el envío forzado de un paquete RST;

5) a continuación, el atacante puede trabajar en nombre de la víctima y con sus Derechos de cuenta;

6) el atacante se ve obligado a volver a conectarse al recurso objetivo, creyendo con razón que se ha producido un error de conexión de hardware. El atacante le envía un RST;

7) cuando el hacker termina de trabajar con el sistema, deja de enviar RST y desactiva ARP-relay;

8) el usuario pirateado puede trabajar con el sistema nuevamente.

Como es fácil de entender a partir de la descripción, para implementar un ataque de este tipo, debe estar conectado a un conmutador, que es el atacado. Es decir, estar en la misma red local con la víctima.

En un caso más simple, un atacante podría intentar hackear la sesión de otra persona mediante la suplantación de cookies.

Aquí hay un pequeño ejemplo de un ataque similar en la práctica.

Para implementarlo, necesita un sniffer como Wireshark, un navegador (como Firefox) y un Editor de Cookies (puede usar add-on para Firefox).

El usuario atacado se conecta al portal de la red social.

El ladrón realiza un rastreo de tráfico. Al final de la interceptación del tráfico, el atacante debe encontrar las cookies transmitidas por el usuario. Puedes hacerlo en Wireshark de la siguiente manera. Presione Ctrl + F o Edit-Find Packet. En el campo By: debe seleccionar String y Search In, la opción Packet details, en el campo de texto debe especificar Set-Cookie.

Cuando se encuentre el paquete deseado, debe hacer clic con el botón derecho del mouse y seleccionar "Follow TCP Stream". A continuación, en este hilo, puede encontrar un paquete similar al anterior.

Esta es la cookie necesaria. A continuación, abra el Editor de Cookies (Tools-Cookie Editor). Luego haga clic en Agregar y especifique lo siguiente:

Name: _twitter_sess

Content: copy paste the information from the TCP Stream (see the red box in the Session Cookie Found from TCP Stream picture)

Domain: .twitter.com

Path: /

En el caso de una implementación exitosa, ahora el atacante no necesita proporcionar credenciales para iniciar sesión en el sitio, solo tiene que ir a la página.

Se realizan brevemente los siguientes pasos:

1) intercepción de tráfico;

2) detección de un paquete que contiene Set-Cookie;

3) configuración de Cookies en el Editor De cookies add-on;

4) acceso al sitio correcto.

Fijación de sesión (Session Fixation).

Para llevar a cabo este ataque, el atacante no necesita el id de la sesión de otra persona, es suficiente establecer el id de su sesión para un usuario legítimo que haya pasado la autorización. Al igual que en el caso anterior, se crea una situación en la que el atacante y el usuario legítimo comparten el mismo id de sesión.

La fijación de sesión (Session Fixation) es un método de ataque que fuerza el id de sesión a un valor específico. Dependiendo de la funcionalidad del sitio atacado, se pueden aplicar muchos métodos diferentes para "confirmar" el id de sesión. Luego, se confirma la identificación de la sesión del usuario y el atacante espera a quienes inicien sesión. Una vez que el usuario hace esto, el atacante usa un valor predefinido de id de sesión para obtener su identificación en línea con todas las consecuencias que conlleva.

Hay dos tipos de sistemas de gestión de sesiones: "libre" y "estricto". El tipo de sesión se determina en función de cómo se forman los valores de los identificadores. El primer tipo de sistemas permite a los navegadores web especificar cualquier identificador. El segundo tipo de sistema solo acepta los valores generados en el servidor. En los sistemas libres, el identificador arbitrario de la sesión se procesa sin tener que acceder al sitio web. Los sistemas estrictos requieren que el atacante mantenga una "sesión de trampa" con acceso periódico al sitio web para evitar tiempos de espera por inactividad.

Sin una protección activa contra la fijación de la sesión, se puede lanzar un ataque contra cualquier sitio web que use las sesiones para identificar la autenticidad de los usuarios. Los sitios web que usan identificadores de sesión generalmente usan Cookies, también se usan URL y campos de formulario ocultos. Desafortunadamente, las sesiones basadas en Cookies son más fáciles de atacar.

A diferencia de robar las id de sesión de los usuarios que se ejecutan después de que inician sesión en un sitio web, la fijación de la sesión ofrece oportunidades significativamente mayores para el ataque. La parte activa del ataque se realiza antes de que los usuarios inicien sesión.

Considere un ejemplo de una confirmación clásica de una sesión de usuario.

Hay tres pasos de fijación:

1) instalación;

2) fijación;

3) entrada.

En el primer paso, el atacante instala una "sesión trampa" en el sitio atacado y obtiene esa id de sesión. O bien, el atacante para atacar puede elegir un identificador de sesión aleatorio. Pero en este caso, el valor establecido por la sesión de trampa debe mantenerse (para "estar vivo") con las conexiones repetidas al sitio web.

Luego, en el siguiente paso, el atacante coloca el valor de la sesión trampa en el navegador del usuario y captura la identificación de la sesión del usuario. Y en la tercera etapa, el atacante espera hasta que el usuario inicie sesión en el sistema del sitio atacado. Una vez que el usuario hace esto, se utiliza el valor de id de sesión fija y el atacante puede comenzar a trabajar con el sistema comprometido.

Puede utilizar uno de los siguientes métodos para confirmar el id de sesión de usuario:

emisión de cookies utilizando un script de cliente;

emitir un nuevo valor de id de sesión en una cookie utilizando un script de cliente. La programación entre sitios en los puntos débiles del sistema de seguridad del sitio web se puede utilizar para cambiar el valor actual de la cookie.

http://example/<script>document.cookie="sessionid=1234;%20domain=.example.Som";< / script>.idc

Aquí hay un ejemplo de emitir una cookie usando una META etiqueta. Este método es efectivo, especialmente cuando el bloqueador de programación entre sitios evita que las etiquetas de script HTML se inyecten, pero no las etiquetas META.

http://example/<meta%20http-equiv=Set-Cookie%20content="sessionid=1234;%20domain=.example.Som">.idc

Emisión de cookies utilizando el encabezado de respuesta HTTP.

Un atacante hace que el sitio web de destino o cualquiera de sus Subdominios emitan una cookie con un id de sesión. Esto se puede lograr de muchas maneras:

hackear un servidor web en un dominio (por ejemplo, un servidor mal mantenido);

infección del servidor DNS personalizado, casi con la adición del servidor web del atacante al dominio atacado (este tipo de ataque ya se ha descrito un poco en las publicaciones sobre DNS);

instalación de un servidor web malicioso en el dominio atacado (por ejemplo, en una estación de trabajo en el dominio Windows2000, todas las estaciones de trabajo también están en el dominio DNS);

el uso de un ataque de partición de respuesta HTTP.

También vale la pena señalar aquí que un ataque de confirmación de sesión prolongada se puede realizar emitiendo cookies persistentes (por ejemplo, con una vida útil de 10 años) que mantendrán la confirmación de la sesión incluso después de que el usuario reinicie la computadora. Aquí hay un ejemplo:

http://example/<script>document.cookie="sessionid=1234;%20Expires=Friday,%201-Jan2017%2000:00:00%20GMT";</script>.idc

Sesión de envenenamiento (session Poisoning).

La amenaza de una sesión envenenada se produce si un atacante tiene la capacidad de instalar su script PHP en el servidor donde se ejecuta la aplicación atacada. La esencia del ataque es que si las aplicaciones PHP se ejecutan en el mismo servidor, es muy probable que, conociendo el id de sesión, el atacante pueda trabajar con los datos de la sesión creada en la aplicación atacada. El envenenamiento es posible si la aplicación atacada tiene un error que permite la ejecución de código arbitrario y si la aplicación web se ejecuta en el servidor junto con las aplicaciones de otros usuarios de alojamiento.

El objetivo de este ataque es obtener acceso a los valores de sesión con capacidad de lectura / escritura. Si tiene éxito, el atacante podría Leer y/o falsificar cualquier valor almacenado en la sesión. Los envenenamientos se utilizan para obtener datos personales de otros usuarios, así como para modificar su propia sesión, hacerse pasar por otro y/o mejorar los privilegios.

Aquí está el ejemplo más simple de este ataque:

$var = $_GET["something"];

$_SESSION["$var"] = $var2;

Autenticación mediante formularios.

Cuando el cliente entra en la página e ingresa el nombre de usuario y la contraseña, sus credenciales se transfieren al servidor. Si la autenticación se realiza correctamente, el servidor genera un ticket de sesión para este usuario y, en todas las llamadas posteriores al servidor, ya se utiliza este ticket, cuyos datos se almacenan en la cookie. Por defecto, el tiempo de vida del boleto es de 30 minutos. Al final de este tiempo, el boleto puede renovarse automáticamente. En el caso de que no haya más visitas durante un cierto período de tiempo, el servidor envía un mensaje al cliente pidiéndole que "olvide" este ticket, como resultado de lo cual el navegador elimina esta cookie y el usuario debe volver a ingresar las credenciales para iniciar sesión.

Parecería que todo es bastante lógico y correcto. Pero un cliente (o más bien un atacante) puede pedirle periódicamente al servidor que renueve su boleto, esencialmente un número ilimitado de veces. Es decir, el servidor no controla cuántas veces se renovó el boleto. Y el atacante simplemente puede ignorar la oferta recibida del servidor de "olvidar" su boleto y continuar renovándolo.

Por lo tanto, si un atacante pudiera robar una cookie de ticket, podría usar la sesión del usuario.

Cross Site Request Forgery.

El viejo CSRF también es relevante para .NET. Recuerde que CSRF es un tipo de ataque contra los visitantes de sitios web que aprovechan las fallas del protocolo HTTP. Si la víctima accede a un sitio creado por un atacante, en su nombre se envía en secreto una solicitud a otro servidor (por ejemplo, un servidor de sistema de pago) que realiza una operación maliciosa (por ejemplo, transferencia de dinero a la cuenta del atacante).

Para llevar a cabo este ataque, se deben cumplir varias condiciones. Primero, la víctima debe autenticarse en el servidor en el que se ejecuta la solicitud. Además, esta solicitud no debe requerir ningún

confirmaciones por parte del usuario que no pueden ser automatizadas, es decir, que no pueden ser manipuladas por el script atacante.

Como ejemplo, considere una situación en la que un usuario inicia sesión con autenticación basada en los mismos formularios de los que hablamos un poco antes. El servidor autentica al usuario y emite una respuesta que incluye el ticket del usuario en la cookie. Dicho esto, el sitio web del banco confía en cualquier solicitud que reciba con un boleto de cookie válido. Además, el usuario, sin terminar la sesión forzada en el sitio web del banco, visita otro sitio, www.hacker.com que contiene un formulario HTML que oculta el envío de los siguientes datos en el formulario:

</form>

Tenga en cuenta que el formulario enviará los datos a la página web del banco. Esta es la parte" entre sitios " de CSRF. Luego, bajo cualquier pretexto, se le pide al usuario que haga clic en un botón que enviará secretamente los datos del formulario. Al enviar el formulario, el navegador enviará automáticamente un boleto a la cookie para el dominio solicitado, porque el usuario todavía está formalmente comprometido en el sitio web del banco. Como resultado, la solicitud se realizará en el sitio web del banco. Vale la pena señalar que el uso de HTTPS no previene los ataques CSRF. Un sitio malicioso puede enviar una solicitud tan fácilmente como una solicitud insegura.

Estos ataques son posibles debido al hecho de que el navegador almacena cookies emitidas por la aplicación, estas cookies contienen entradas de sesión de usuarios validados, y finalmente el navegador envía a la aplicación web todas las cookies asociadas con el dominio, independientemente de cómo se creó la solicitud a la aplicación en el navegador.

Oleg Petukhov, abogado en el campo del derecho internacional y la protección de datos personales, especialista en información seguridad, protección de la información y datos personales.

Canal de Telegram: https://t.me/protecciondelainformacion1

Grupo de Telegramas: https://t.me/protecciondelainformacion2

Sitio web: https://legascom.ru

Correo electrónico: online@legascom.ru

#proteccióndelainformación #seguridaddelainformación

Ataques na web através do gerenciamento de sessão.

Ataques a aplicativos da web através do sistema de gerenciamento de sessão.

Outro ponto vulnerável são os aplicativos da web. É claro que o desenvolvimento de portais corporativos da web geralmente é confiado a programadores profissionais da web, mas um administrador de sistemas e, mais ainda, um especialista em segurança devem estar cientes das vulnerabilidades existentes na web. Além disso, em pequenas empresas, o sysadmin geralmente está envolvido no desenvolvimento e manutenção de um portal corporativo. Portanto, as informações a seguir serão úteis para muitos.

Os portais web modernos usam principalmente o Apache como servidor web. Existe, é claro, o IIS (Internet Information Services) que roda no Windows, mas a maioria dos hosts ainda usa o pacote FreeBSD/Linux+Apache. Normalmente, o MySQL ou o PostgreeSQL são usados para armazenar os dados com os quais um portal da web funciona. Oracle pode ser usado em sistemas industriais de alta carga.

Normalmente, PHP ou Perl são usados como linguagem de script. Existem também ferramentas de alto nível para o desenvolvimento de soluções de portal da Microsoft, mas não as abordaremos nesta seção devido à sua menor prevalência, em comparação com o FreeBSD gratuito, Apache, MySQL, PHP.

Como exemplo prático, considere ataques em um aplicativo PHP por meio de um sistema de gerenciamento de sessão. As principais razões para esses ataques serem possíveis são a falta de verificação do ID de sessão do Usuário e a falta de verificação dos dados armazenados na sessão.

Considere possíveis ataques ao aplicativo.

Sessão de roubo (session Hijacking).

O objetivo do ataque é usar um identificador de sessão pertencente a um usuário legítimo para se passar pelo proprietário da sessão. Você pode descobrir o ID da sessão de outra pessoa interceptando o tráfego de um usuário legítimo, organizando um ataque XSS ou usando Força bruta.

Algoritmo geral de ataque seguinte:

1) o atacante coleta informações sobre o endereço IP da vítima e o recurso a ser acessado;

2) em seguida, é necessário esperar que o atacante se conecte ao recurso de destino;

3) em seguida, o atacante precisa executar ARP relay;

4) Quando a vítima se conecta ao recurso alvo e começa a trabalhar com ele, o atacante verá uma nova conexão ativa no Sniffer. Em seguida, o atacante executa o ataque por dessincronização TCP/IP, que já foi descrito anteriormente. A conexão da vítima "cai" ao forçar o envio do pacote RST;

5) em seguida, o atacante pode trabalhar em nome da vítima e com seus direitos de conta;

6) o atacante é forçado a se reconectar ao recurso de destino, acreditando corretamente que houve uma falha de hardware na conexão. O atacante envia um RST;

7) quando o hacker terminar de trabalhar com o sistema, ele pára de enviar RST e desabilita o ARP-relay;

8) o usuário comprometido pode trabalhar com o sistema novamente.

Como pode ser facilmente entendido a partir da descrição, para implementar tal ataque, você precisa estar conectado ao mesmo switch que o atacante. Ou seja, estar na mesma rede local com a vítima.

Em um caso mais simples, um invasor pode tentar invadir a sessão de outra pessoa usando a substituição de cookies.

Aqui está um pequeno exemplo de tal ataque na prática.

Para implementá-lo, você precisa de um sniffer como Wireshark, um navegador (por exemplo, Firefox) e um editor de Cookies (você pode usar o Add-on do Firefox).

O usuário alvo se conecta ao portal da rede social.

O atacante faz um sniffing de tráfego. Quando o tráfego é interceptado, o atacante precisa encontrar os cookies transmitidos pelo Usuário. Você pode fazer isso no Wireshark da seguinte maneira: Pressione Ctrl + F ou Edit-Find Packet. No campo By: selecione String e Search In, opção Packet details, no campo de texto você precisa especificar Set-Cookie.

Quando o pacote desejado for encontrado, clique com o botão direito do mouse e selecione "Follow TCP Stream". Em seguida, você pode encontrar um pacote semelhante a este tópico.

Este é um cookie necessário. Em seguida, você precisa abrir o editor de cookies (Tools-Cookie Editor). Em seguida, pressione Add e especifique o seguinte:

Name: _twitter_sess

Content: copy paste the information from the TCP Stream (see the red box in the Session Cookie Found from TCP Stream picture)

Domain: .twitter.com

Path: /

Se a implementação for bem-sucedida, agora o invasor não precisa fornecer credenciais para entrar no site, basta acessar a página.

As seguintes etapas são executadas brevemente:

1) interceptação de tráfego;

2) detectar um pacote contendo um cookie Set;

3) definir cookies no Cookie Editor add-on;

4) acesso ao site adequado.

Fixação de sessão (Session Fixation).

Para realizar este ataque, um invasor não precisa do ID da sessão de outra pessoa, basta definir o ID da sessão de outra pessoa para um usuário legítimo autenticado. Como no caso anterior, cria-se uma situação em que o atacante e o usuário legítimo compartilham o mesmo ID de sessão.

A fixação de sessão é um método de ataque que força o ID da sessão a um determinado valor. Dependendo da funcionalidade do site que está sendo atacado, muitos métodos diferentes podem ser usados para "bloquear" o ID da sessão. Em seguida, o ID da sessão do Usuário é fixado e o invasor aguarda aqueles que farão login. Uma vez que o usuário faz isso, o invasor usa um valor de ID de sessão predefinido para obter sua identidade on-line com todas as consequências que isso implica.

Existem dois tipos de sistemas de gerenciamento de sessão: "free" e "strict". O tipo de sessão é determinado de acordo com a forma como os valores dos identificadores são formados. O primeiro tipo de sistema permite que os navegadores da web especificem qualquer identificador. O segundo tipo de Sistema aceita apenas os valores gerados no servidor. Em sistemas livres, uma sessão de identificação arbitrária é processada sem acesso ao site. Sistemas rigorosos exigem que um invasor mantenha uma "sessão-armadilha" com acesso periódico ao site para evitar tempos de inatividade.

Sem proteção ativa contra a fixação de sessão, um ataque pode ser realizado contra qualquer site que use as sessões para identificar a autenticidade dos usuários. Os sites que usam IDs de sessão geralmente usam cookies, URLs e campos de formulário ocultos também são usados. Infelizmente, as sessões baseadas em cookies são mais fáceis de atacar.

Ao contrário de roubar os IDs de sessão dos usuários depois que eles fazem login em um site, a captura de sessão oferece oportunidades significativamente mais amplas de ataque. A parte ativa do ataque é feita antes que os usuários façam login no sistema.

Considere um exemplo de fixação clássica de uma sessão de usuário.

Existem três etapas de fixação:

1) instalação;

2) fixação;

3) entrada.

Na primeira etapa, o invasor instala uma "sessão-armadilha" no site que está sendo atacado e recebe esse ID de sessão. Ou um atacante pode escolher um ID de sessão aleatório para atacar. Mas, nesse caso, o valor definido pela sessão de armadilha deve ser mantido (para "estar vivo") com conexões repetidas ao site.

Em seguida, na próxima etapa, o invasor coloca o valor da sessão de armadilha no navegador do Usuário e captura o ID da sessão do Usuário. E na terceira etapa, o invasor espera até que o usuário faça login no site que está sendo atacado. Uma vez que o usuário faça isso, o valor de ID de sessão fixa será usado e o invasor poderá começar a trabalhar com o sistema comprometido.

Um dos seguintes métodos pode ser usado para fixar o ID da sessão do Usuário:

emissão de cookies usando o script do cliente;

fornecer um novo valor de ID de sessão no cookie usando o script do cliente. A programação entre sites em pontos fracos do sistema de segurança do site pode ser usada para alterar o valor atual do cookie.

http://example/<script>document.cookie="sessionid=1234;%20domain=.example.</script>>.idc

Aqui está um exemplo da emissão de um cookie usando uma meta tag. Esse método é eficaz, especialmente quando o bloqueador de programação entre sites impede a injeção de tags de scripts HTML, mas não de tags META.

http://example/<meta%20http-equiv=Set-Cookie%20content="sessionid=1234;%20domain=.example.som".idc

Emissão de cookies usando o cabeçalho de resposta HTTP.

Um invasor faz com que o site de destino ou qualquer um de seus subdomínios emitam um cookie com um ID de sessão. Isso pode ser feito de várias maneiras:

hackear um servidor da Web em um domínio (por exemplo, um servidor mal suportado);

infectar um servidor DNS personalizado, quase adicionando o servidor web do invasor ao domínio que está sendo atacado (esse tipo de ataque já foi descrito um pouco nas postagens sobre DNS);

instalar um servidor web malicioso no domínio atacado (por exemplo, em uma estação de trabalho no domínio Windows2000, todas as estações de trabalho também estão no domínio DNS);

usando um ataque de quebra de resposta HTTP.

Também vale a pena notar aqui que um ataque de fixação de sessão prolongada pode ser realizado emitindo cookies permanentes (por exemplo, com uma vida útil de 10 anos) que manterão a fixação da sessão mesmo após o usuário reiniciar o computador. Aqui está um exemplo:

http://example/<script>document.cookie="sessionid=1234;%20Expires=Friday,%201-Jan2017%2000:00:00%20GMT";</script>.idc

Envenenamento por sessão (session Poisoning).

A ameaça de uma sessão envenenada ocorre quando um invasor tem a capacidade de instalar seu script PHP no servidor onde o aplicativo está sendo executado. A essência do ataque é que, se os aplicativos PHP forem executados no mesmo servidor, é provável que, sabendo o ID da sessão, o invasor possa trabalhar com os dados da sessão criados no aplicativo que está sendo atacado. O envenenamento é possível se o aplicativo atacado tiver um erro que permita a execução de código arbitrário e se o aplicativo da web estiver sendo executado em um servidor junto com os aplicativos de outros usuários hospedados.

O objetivo deste ataque é obter acesso de leitura/gravação aos valores da sessão. Se for bem-sucedido, o atacante será capaz de ler e/ou falsificar qualquer valor armazenado na sessão. O envenenamento é usado para obter dados pessoais de outros usuários, bem como para modificar sua própria sessão, para se passar por outro e/ou aumentar os privilégios.

Este é o exemplo mais simples deste ataque.:

$var = $_GET["something"];

$_SESSION["$var"] = $var2;

Autenticação por meio de formulários.

Quando um cliente entra na página e digita o login e a senha, suas credenciais são transferidas para o servidor. Se a autenticação for bem-sucedida, o servidor criará um ticket de sessão para o usuário em questão e, em todas as visitas subsequentes ao servidor, esse ticket será usado, cujos dados serão armazenados no cookie. Por padrão, o tempo de vida do bilhete é de 30 minutos. Após esse período, O bilhete pode ser renovado automaticamente. No caso de não haver mais acessos dentro de um determinado intervalo de tempo, o servidor envia ao cliente uma mensagem pedindo para "esquecer" esse ticket, como resultado do qual o navegador exclui esse cookie e o usuário precisa inserir as credenciais novamente para entrar no sistema.

Parece que tudo é bastante lógico e correto. Mas o cliente (ou melhor, um invasor) pode solicitar periodicamente ao servidor que renove seu ticket, na verdade, um número ilimitado de vezes. Ou seja, o servidor não controla quantas vezes o bilhete foi renovado. E um invasor pode simplesmente ignorar a oferta recebida do servidor para "esquecer" seu bilhete e continuar a renová-lo.

Assim, se um invasor conseguir roubar um cookie com um bilhete, ele poderá usar a sessão do Usuário.

Cross Site Request Forgery.

O bom e velho CSRF também é relevante para o .NET. lembre - se de que o CSRF é um tipo de ataque a visitantes de sites que explora as falhas do protocolo HTTP. Se uma vítima acessa um site criado por um invasor, uma solicitação é secretamente enviada em seu nome para outro servidor (por exemplo, um servidor de um sistema de pagamento) para realizar uma operação maliciosa (por exemplo, transferir dinheiro para a conta do invasor).

Para realizar este ataque, várias condições devem ser atendidas. Primeiro, a vítima deve ser autenticada no servidor em que a solicitação está sendo executada. Além disso, este pedido não deve exigir qualquer

confirmações do usuário que não podem ser automatizadas, ou seja, que não podem ser adulteradas por um script de ataque.

Como exemplo, considere a situação em que um usuário faz login usando a autenticação com base nos mesmos formulários de que falamos anteriormente. O servidor autentica o Usuário e fornece uma resposta que inclui o Ticket do usuário no cookie. Ao mesmo tempo, o site do banco confia em qualquer solicitação que receba com um bilhete válido em um cookie. Além disso, o usuário, sem concluir a sessão forçada no site do banco, visita outro site, www.hacker.com que contém um formulário HTML que esconde o envio no formulário a seguir:

</form>

Observe que o formulário enviará os dados para o site do banco. Esta é a parte" Cross-Site " do CSRF. Em seguida, sob qualquer pretexto, o Usuário é solicitado a clicar em um botão que enviará secretamente os dados do formulário. Ao enviar um formulário, o navegador enviará automaticamente um bilhete para o cookie do domínio solicitado, porque o usuário ainda está formalmente logado no site do banco. Como resultado, o pedido será feito no site do banco. Vale ressaltar que o uso de HTTPS não impede ataques CSRF. Um site malicioso pode enviar uma solicitação tão facilmente quanto uma solicitação insegura.

Esses ataques são possíveis porque o navegador armazena cookies emitidos pelo aplicativo, esses Cookies incluem tickets de sessão de usuários autenticados e, finalmente, o navegador envia para o aplicativo da web todos os cookies associados ao domínio, independentemente de como a solicitação do aplicativo foi criada no navegador.

Petukhov Oleg, advogado de Direito Internacional e proteção de dados pessoais, especialista em informação segurança, proteção de informações e dados pessoais.

Canal do Telegram: https://t.me/protecaodaInformacao

Grupo em Telegram: https://t.me/protecaodaInformacao1

Site: https://legascom.ru

Correio eletrónico: online@legascom.ru

#segurançadaInformação #Segurançadainformação

Ataques na web através do gerenciamento de sessões.

Ataques a aplicações web através do sistema de gerenciamento de sessões.

Outro ponto vulnerável são as aplicações web. É claro que o desenvolvimento de portais da web corporativos geralmente é confiado a programadores profissionais da web, mas um administrador de sistemas e especialmente um especialista em segurança da informação deve estar ciente das vulnerabilidades existentes nos aplicativos da web. Além disso, em pequenas empresas, o administrador do sistema geralmente desenvolve e mantém um portal corporativo. Portanto, as informações a seguir serão úteis para muitos.

Os portais da web modernos usam principalmente o Apache como servidor da web. Existe, é claro, o IIS (Internet Information Services) rodando no Windows, mas a maioria dos serviços de hospedagem ainda usa uma combinação de FreeBSD/Linux+Apache. MySQL ou PostgreeSQL é geralmente usado para armazenar os dados com os quais o portal da web trabalha. O Oracle pode ser usado em sistemas industriais de alta carga.

PHP ou Perl é geralmente usado como uma linguagem de script. Também existem ferramentas de alto nível para o desenvolvimento de soluções de portal da Microsoft, mas nesta seção não as abordaremos devido à sua menor prevalência em comparação com FreeBSD, Apache, MySQL, PHP gratuitos.

Como exemplo prático, considere ataques a uma aplicação PHP através de um sistema de gerenciamento de sessões. Os principais motivos para a possibilidade desses ataques são a falta de verificação do ID da sessão do Usuário e a falta de verificação dos dados armazenados na sessão.

Vejamos possíveis ataques ao aplicativo.

Sequestro De Sessão.

A essência do ataque é que um invasor usa um identificador de sessão pertencente a um usuário legítimo para se passar pelo proprietário da sessão. Você pode descobrir o ID da sessão de outra pessoa interceptando o tráfego de um usuário legítimo, organizando um ataque XSS ou por força bruta.

O algoritmo geral do ataque é o seguinte:

1) o invasor coleta informações sobre os endereços IP da vítima e o recurso a ser acessado.;

2) então você precisa esperar que o invasor se conecte ao recurso de destino.;

3) em seguida, o atacante precisa iniciar o ARP relay;

4) Quando a vítima se conectar ao recurso de destino e começar a trabalhar com ele, o invasor verá uma nova conexão ativa no sniffer. Em seguida, o hacker realiza um ataque de dessincronização TCP/IP, que já foi descrito anteriormente. A conexão da vítima "cai" ao enviar à força um pacote RST;

5) Além disso, o atacante pode trabalhar em nome da vítima e com seus direitos de conta;

6) o invasor é forçado a se reconectar ao recurso de destino, acreditando corretamente que ocorreu uma falha de conexão de hardware. O atacante lhe envia um RST;

7) quando o hacker termina de trabalhar com o sistema, ele para de enviar o RST e desativa o ARP-relay;

8) o usuário hackeado pode voltar a trabalhar com o sistema.

Como é fácil entender pela descrição, para implementar tal ataque, é necessário estar conectado ao mesmo switch que o atacado. Em outras palavras, eles estão realmente na mesma rede local que a vítima.

Em um caso mais simples, um invasor pode tentar invadir a sessão de outra pessoa falsificando cookies.

Aqui está um pequeno exemplo de tal ataque na prática.

Para implementá-lo, você precisa de um sniffer, como o Wireshark, um navegador (como o Firefox) e um editor de cookies (você pode usar o complemento para o Firefox).

O usuário atacado se conecta ao portal da rede social.

O hacker fareja o tráfego. Após a conclusão da interceptação de tráfego, o invasor precisa encontrar os cookies transmitidos pelo Usuário. Você pode fazer isso no Wireshark da seguinte maneira. Pressione Ctrl+F ou Edit-Find Packet. No campo By:, selecione String and Search In, a opção Packet details, e especifique o Set Cookie no campo text.

Quando o pacote desejado for encontrado, clique com o botão direito e selecione "Follow TCP Stream". Mais adiante neste fluxo, você pode encontrar um pacote semelhante ao mostrado.

Este é o cookie necessário. Em seguida, você precisa abrir o editor de cookies (ferramentas - Editor de cookies). Em seguida, clique em Adicionar e especifique o seguinte:

Nome: _twitter_sess

Conteúdo: Copie e cole as informações do Stream TCP (veja a caixa vermelha na imagem Session Cookie Found from TCP Stream)

Domínio: .twitter.com

Caminho: /

Em caso de implementação bem-sucedida, o invasor agora não precisa fornecer credenciais para efetuar login no site, basta acessar a página.

As seguintes ações são executadas brevemente:

1) interceptação de tráfego;

2) detectando um pacote contendo um Cookie definido;

3) Configurando Cookies no complemento Editor de cookies;

4) acessando o site desejado.

Fixação De Sessão.

Para realizar esse ataque, o invasor não precisa do identificador da sessão de outra pessoa, basta definir o identificador de sua sessão para um usuário legítimo que tenha passado a autorização. Como no caso anterior, uma situação é criada quando um invasor e um usuário legítimo têm o mesmo identificador de sessão.

A fixação de sessão é um método de ataque que define forçosamente o identificador de sessão para um valor específico. Dependendo da funcionalidade do site atacado, muitos métodos diferentes podem ser usados para "corrigir" o ID da sessão. Em seguida, o ID da sessão do Usuário é corrigido e o invasor aguarda aqueles que farão login. Assim que o usuário faz isso, o invasor usa o valor predefinido do ID da sessão para obter sua identificação online com todas as consequências decorrentes.

Existem dois tipos de sistemas de gerenciamento de sessão: "free "e"strict". O tipo de sessão é determinado dependendo de como os valores do identificador são gerados. O primeiro tipo de sistema permite que os navegadores da web especifiquem qualquer identificador. O segundo tipo de Sistema aceita apenas valores gerados no servidor. Em sistemas livres, um identificador de sessão arbitrário é processado sem acessar o site. Sistemas estritos exigem que um invasor mantenha uma "sessão de interceptação" com acesso periódico ao site para evitar tempos limite de inatividade.

Sem proteção ativa contra fixação de sessão, um ataque pode ser lançado contra qualquer site que use sessões para autenticar usuários. Os sites que usam identificadores de sessão geralmente usam cookies, e URLs e campos de formulário ocultos também são usados. Infelizmente, as sessões baseadas em cookies são mais fáceis de atacar.

Ao contrário do roubo de IDs de sessão de usuário realizado depois que eles fazem logon em um site, a fixação de sessão oferece oportunidades significativamente maiores de ataque. A parte ativa do ataque é feita antes que os usuários efetuem login no sistema.

Vejamos um exemplo de fixação clássica de sessão de usuário.

Existem três estágios de fixação:

1) Instalação;

2) fixação;

3) entrada.

No primeiro estágio, o invasor instala uma "sessão de armadilha" no site atacado e obtém esse identificador de sessão. Ou um invasor pode escolher um ID de sessão aleatório para atacar. Mas, neste caso, o valor definido pela sessão de trap deve ser mantido (para "estar vivo") com conexões repetidas ao site.

Em seguida, na próxima etapa, o invasor coloca o valor da sessão de interceptação no navegador do Usuário e captura o ID da sessão do Usuário. E na terceira etapa, o invasor espera até que o usuário faça login no sistema do site atacado. Assim que o usuário fizer isso, o valor do identificador de sessão fixo será usado e um invasor poderá começar a trabalhar com o sistema invadido.

Para corrigir o ID da sessão do usuário, um dos seguintes métodos pode ser executado:

emitindo cookies usando um script de cliente;

emitindo um novo valor de ID de sessão em um cookie usando um script de cliente. A programação entre sites em pontos fracos do sistema de proteção de sites pode ser usada para alterar o valor atual do cookie.

http://example / < script>document. cookie="sessionid=1234;%20domain=.example.com";< / script>. idc

Aqui está um exemplo de emissão de um cookie usando uma META tag. Esse método é eficaz, especialmente quando o bloqueador de programação entre sites impede a injeção de tags de script HTML, mas não de metatags.

http://example / <meta%20http-equiv=Set-Cookie%20content="sessionid=1234;%20domain=.example.com">. idc

Emissão de cookies usando o cabeçalho de resposta HTTP.

Um invasor faz com que um cookie com um ID de sessão seja emitido no site de destino ou em qualquer um de seus subdomínios. Isso pode ser feito de diferentes maneiras:

hackear um servidor web no domínio (por exemplo, um servidor mal conservado);

infecção do servidor DNS de um usuário, praticamente com a adição do servidor web de um invasor ao Domínio atacado (esse tipo de ataque já foi descrito nos posts do DNS);

instalar um servidor web malicioso no domínio atacado (por exemplo, em uma estação de trabalho no domínio Windows2000, todas as estações de trabalho também estão localizadas no domínio DNS);

usando um ataque de divisão de resposta HTTP.

Também é importante notar aqui que um ataque de fixação de sessão de longo prazo pode ser realizado emitindo cookies permanentes (por exemplo, com uma vida útil de 10 anos), que manterão a sessão fixa mesmo depois que o usuário reiniciar o computador. Veja um exemplo:

http://example / < script>document.cookie="sessionid=1234;%20expira=sexta-feira,%201-Jan2017%2000:00:00% 20GMT";</script>.idc

Envenenamento De Sessão.

A ameaça de uma sessão envenenada ocorre se um invasor tiver a oportunidade de instalar seu script PHP no servidor onde o aplicativo atacado está sendo executado. A essência do ataque reside no fato de que, se os aplicativos PHP estiverem sendo executados no mesmo servidor, há uma alta probabilidade de que, conhecendo o ID da sessão, o invasor possa trabalhar com os dados da sessão criados no aplicativo atacado. O envenenamento é possível se o aplicativo atacado tiver um erro que permita a execução de código arbitrário e se o aplicativo da web for executado no servidor junto com aplicativos de outros usuários de hospedagem.

O objetivo desse ataque é obter acesso aos valores da sessão de leitura/gravação. Se for bem-sucedido, um invasor poderá ler e/ou falsificar qualquer valor armazenado na sessão. O envenenamento é usado para obter os dados pessoais de outros usuários, bem como para modificar sua própria sessão, personificar outra e/ou aumentar privilégios.

Aqui está o exemplo mais simples desse ataque:

$var = $ _GET ["algo"];

$_SESSION["$var"] = $var2;

Autenticação usando formulários.

Quando um cliente visita a página e digita um nome de usuário e senha, suas credenciais são transmitidas para o servidor. Se a autenticação for bem-sucedida, o servidor gera um ticket de sessão para esse usuário e, para todas as solicitações subsequentes ao servidor, esse ticket já é usado, cujos dados são armazenados em um cookie. Por padrão, a vida útil do ticket é de 30 minutos. Ao final desse período, O boleto poderá ser renovado automaticamente. Se não houver mais solicitações dentro de um determinado intervalo de tempo, o servidor envia uma mensagem ao cliente com uma sugestão para "esquecer" esse ticket, como resultado do qual o navegador exclui esse cookie e o Usuário deve inserir novamente as credenciais para efetuar login.

Parece que tudo é bastante lógico e correto. Mas o cliente (ou melhor, o invasor) pode solicitar periodicamente ao servidor que renove seu ticket, na verdade, um número ilimitado de vezes. Em outras palavras, o servidor não tem controle sobre quantas vezes o ticket foi renovado. E um invasor pode simplesmente ignorar a oferta recebida do servidor para "esquecer" seu ticket e continuar a renová-lo ainda mais.

Assim, se um invasor conseguiu roubar o cookie do ticket, ele poderá usar a sessão do Usuário.

Cross Site Request Forgery.

O bom e velho CSRF também é relevante para .NET. lembre-se de que o CSRF é um tipo de ataque aos visitantes do site que explora as deficiências do protocolo HTTP. Se uma vítima visita um site criado por um invasor, uma solicitação é enviada secretamente em seu nome para outro servidor (por exemplo, para um servidor de Sistema de pagamento) que realiza algum tipo de operação maliciosa (por exemplo, transferir dinheiro para a conta do invasor).

Para realizar este ataque, várias condições devem ser atendidas. Primeiro, a vítima deve estar autenticada no servidor onde a solicitação está sendo feita. Além disso, essa solicitação não deve exigir nenhum

confirmação do usuário, que não pode ser automatizada, ou seja, que não pode ser forjada por um script de ataque.

Como exemplo, considere uma situação em que um usuário efetua login usando autenticação com base nos próprios formulários que discutimos anteriormente. O servidor realiza a autenticação do Usuário e emite uma resposta que inclui o ticket do usuário em um cookie. Ao mesmo tempo, o site do banco confia em qualquer solicitação recebida com um ticket válido no cookie. Em seguida, o usuário visita outro site sem encerrar à força a sessão no site do banco, www.hacker.com , que contém um formulário HTML no qual os seguintes dados estão ocultos no formulário:

< / form>

Observe que o formulário enviará os dados para o site do banco. Esta é a parte "cross-site" do CSRF. Então, sob algum pretexto, o Usuário é solicitado a clicar em um botão que enviará secretamente os dados do formulário. Ao enviar o formulário, o navegador enviará automaticamente um ticket de cookie para o domínio solicitado, porque o usuário ainda está formalmente conectado ao site do banco. Com isso, a solicitação será executada no site do banco. Vale ressaltar que o uso de HTTPS não impede ataques de CSRF. Um site malicioso pode enviar uma solicitação tão facilmente quanto uma solicitação insegura.

Tais ataques são possíveis pelo fato de que os cookies emitidos pelo aplicativo são armazenados no navegador, esses cookies contêm, entre outras coisas, os tickets de sessão de usuários verificados e, finalmente, o navegador envia todos os cookies relacionados ao domínio para o aplicativo da web, independentemente de como a solicitação ao aplicativo foi criada no navegador.

Petukhov Oleg, advogado de Direito Internacional e proteção de dados pessoais, especialista em informação segurança, proteção de informações e dados pessoais.

Canal do Telegram: https://t.me/protecaodaInformacao

Grupo em Telegram: https://t.me/protecaodaInformacao1

Site: https://legascom.ru

Correio eletrónico: online@legascom.ru

#segurançadaInformação #Segurançadainformação

Attacchi al web tramite la gestione delle sessioni.

Attacchi alle applicazioni web tramite il sistema di gestione delle sessioni.

Un'altra vulnerabilità sono le applicazioni web. Naturalmente, lo sviluppo di portali web aziendali è solitamente affidato a programmatori web professionisti, ma un amministratore di sistema e ancora di più uno specialista in is dovrebbe avere un'idea delle vulnerabilità esistenti nel web quando si tratta di bugie. Inoltre, nelle piccole aziende, l'amministratore di sistema è spesso impegnato nello sviluppo e nel supporto di un portale aziendale. Quindi le seguenti informazioni saranno utili a molti.

I portali web moderni utilizzano principalmente Apache come server web. C'è ovviamente IIS (Internet Information Services) in esecuzione su Windows, ma la maggior parte degli host utilizza comunque il bundle FreeBSD/Linux+Apache. Per archiviare i dati con cui funziona il portale web, in genere viene utilizzato MySQL o PostgreSQL. Oracle può essere utilizzato in sistemi industriali ad alto carico.

PHP o Perl è comunemente usato come linguaggio di scripting. Esistono anche strumenti di sviluppo del portale di alto livello di Microsoft, ma in questa sezione non li tratteremo a causa della loro minore prevalenza, rispetto a FreeBSD, Apache, MySQL, PHP gratuiti.

Come esempio pratico, considera gli attacchi a UN'applicazione PHP tramite un sistema di gestione delle sessioni. I motivi principali della possibilità di questi attacchi sono la mancanza di convalida dell'ID di sessione dell'utente e la mancanza di convalida dei dati archiviati nella sessione.

Considera le possibili opzioni per gli attacchi all'applicazione.

Furto di sessione (Session Hijacking).

L'essenza dell'attacco consiste nell'utilizzare un identificatore di sessione appartenente a un utente legittimo da parte di un utente malintenzionato per impersonare il proprietario della sessione. Puoi scoprire l'ID della sessione di qualcun altro intercettando il traffico di un utente legittimo, organizzando un attacco XSS o attraverso la forza bruta.

L'algoritmo generale per l'implementazione dell'attacco è il seguente:

1) l'attaccante raccoglie informazioni sugli indirizzi IP della vittima e sulla risorsa a cui è necessario accedere;

2) quindi è necessario attendere che l'attaccante si connetta alla risorsa di destinazione;

3) Successivamente, l'attaccante deve eseguire ARP relay;

4) quando la vittima si è connessa e ha iniziato a lavorare con la risorsa di destinazione, l'attaccante vedrà una nuova connessione attiva nello Sniffer. Successivamente, il cracker esegue un attacco di desincronizzazione TCP / IP, che è già stato descritto in precedenza. La connessione della vittima «cade» forzando l'invio di un pacchetto RST;

5) successivamente, l'attaccante può lavorare per conto della vittima e con le sue credenziali;

6) l'attaccante è costretto a riconnettersi alla risorsa di destinazione, credendo giustamente che si sia verificato un errore di connessione hardware. L'attaccante gli invia un RST;

7) quando l'hacker ha finito con il sistema, smette di inviare RST e disabilita ARP-relay;

8) l'utente compromesso può lavorare di nuovo con il sistema.

Come non è difficile capire dalla descrizione, per implementare un tale attacco, è necessario essere connessi allo stesso interruttore dell'attaccante. Cioè, essere effettivamente sulla stessa rete locale con la vittima.

In un caso più semplice, un utente malintenzionato potrebbe tentare di hackerare la sessione di qualcun altro tramite lo spoofing dei cookie.

Ecco un piccolo esempio di un attacco simile in pratica.

Per la sua implementazione sono necessari uno sniffer, ad esempio Wireshark, un browser (ad esempio Firefox) e un editor di cookie (è possibile utilizzare un add-on per Firefox).

L'utente attaccato si connette al Portale del social network.

Il cracker sta sniffando il traffico. Al termine dell'intercettazione del traffico, l'attaccante deve trovare i cookie trasmessi dall'utente. Puoi farlo in Wireshark come segue. Stampa Ctrl + F o Modifica-Trova pacchetto. Nel campo da: è necessario selezionare String e Search In, L'opzione Dettagli pacchetto, nel campo di testo è necessario specificare Set-Cookie.

Quando viene trovato il pacchetto desiderato, è necessario fare clic con il pulsante destro del mouse e selezionare «Segui flusso TCP». Più avanti in questo thread è possibile trovare un pacchetto simile a quello fornito.

Questo è il cookie necessario. Successivamente, è necessario aprire L'Editor Cookie (Tools-Cookie Editor). Quindi fare clic su Aggiungi e specificare quanto segue:

Name: _twitter_sess

Content: copy paste the information from the TCP Stream (see the red box in the Session Cookie Found from TCP Stream picture)

Domain: .twitter.com

Path: /

Se l'implementazione ha esito positivo, ora l'utente malintenzionato non deve fornire le credenziali per accedere al sito, è sufficiente accedere alla pagina.

Vengono eseguite brevemente le seguenti operazioni:

1) intercettazione del traffico;

2) rilevamento di un pacchetto contenente Set-Cookie;

3) Impostazione dei Cookie Nell'Editor dei Cookie add-on;

4) contattare il sito desiderato.

Fissazione della sessione (Session Fixation).

Per eseguire questo attacco, un utente malintenzionato non ha bisogno dell'ID della sessione di qualcun altro, è sufficiente impostare l'ID della sessione su un utente legittimo che ha superato l'autorizzazione. Come nel caso precedente, viene creata una situazione in cui un utente malintenzionato e un utente legale condividono lo stesso ID di sessione.

Session Fixation (Session Fixation) è un metodo di attacco che forza l'impostazione di un ID di sessione su un valore specifico. A seconda della funzionalità del sito attaccato, è possibile applicare molti metodi diversi per «bloccare» l'ID di sessione. L'ID della sessione utente viene quindi acquisito e l'attaccante attende coloro che accederanno. Una volta che l'utente lo fa, l'attaccante utilizza il valore predefinito dell'ID di sessione per ottenere la sua identità online con tutte le conseguenze che ne derivano.

Esistono due tipi di sistemi di gestione delle sessioni: «libero» e «rigoroso». Il tipo di sessione viene determinato in base a come vengono generati i valori ID. Il primo tipo di sistemi consente ai browser Web di specificare qualsiasi identificatore. Il secondo tipo di sistema accetta solo i valori generati sul server. Nei Sistemi liberi, un identificatore arbitrariosessione viene gestita senza alcun riferimento al sito web. I sistemi rigorosi richiedono che un utente malintenzionato mantenga un "session trap" con visite periodiche a un sito web per prevenire timeout di inattività.

Senza una difesa attiva contro il commit della sessione, un attacco può essere lanciato contro qualsiasi sito web che utilizza le sessioni per identificare l'autenticità degli utenti. I siti Web che utilizzano ID di sessione in genere applicano Cookie, vengono applicati anche URL e campi modulo nascosti. Sfortunatamente, le sessioni basate sui Cookie sono più facili da attaccare.

A differenza del furto degli ID di sessione degli utenti eseguiti dopo il loro accesso al sito web, il commit della sessione offre opportunità significativamente più ampie per l'attacco. La parte attiva dell'attacco viene eseguita prima che gli utenti accedano.

Considera l'esempio di un classico commit della sessione utente.

Ci sono tre fasi di fissazione:

1) installazione;

2) fissaggio;

3) occorrenza.

Nella prima fase, un utente malintenzionato imposta un "session Trap" sul sito attaccato e ottiene questo ID di sessione. Oppure un utente malintenzionato per l'attacco può scegliere un ID di sessione casuale. Ma in questo caso, il valore impostato dalla sessione Trap deve essere mantenuto (per «essere vivo») con riconnessioni al sito web.

Quindi, nella fase successiva, l'attaccante inserisce il valore della sessione Trap nel browser dell'utente e acquisisce l'ID della sessione dell'utente. E nella terza fase, l'attaccante attende che l'utente acceda al sito attaccato. Una volta che l'utente lo fa, il valore dell'ID di sessione fisso verrà utilizzato e l'attaccante può iniziare a lavorare con il sistema compromesso.

È possibile eseguire uno dei seguenti metodi per eseguire il commit dell'ID sessione utente:

emissione di cookie utilizzando uno script client;

emissione di un nuovo valore ID sessione nel cookie utilizzando uno script client. La programmazione cross-site nei punti deboli del sistema di protezione del sito web può essere utilizzata per modificare il valore corrente del cookie.

http://example/<script>document.cookie="sessionid=1234;%20domain=.example.com";< / script>.idc

Ecco un esempio di emissione di cookie utilizzando un meta tag. Questo metodo è efficace soprattutto quando il blocco della programmazione cross-site impedisce l'iniezione di tag di script HTML, ma non di META tag.

http://example/<meta%20http-equiv=Set-Cookie%20content="sessionid=1234;%20domain=.example.pesce gatto">.idc

Emissione di cookie utilizzando l'intestazione di risposta HTTP.

Un utente malintenzionato chiama il sito Web di destinazione o uno qualsiasi dei suoi sottodomini per emettere un cookie con un ID di sessione. Questo può essere fatto in diversi modi:

hacking di un server Web in un dominio (ad esempio un server mal gestito);

infezione del server DNS personalizzato, praticamente con l'aggiunta del server Web dell'attaccante al dominio attaccato (questo tipo di attacco è già stato descritto un po ' nei post sul DNS);

installazione di un server Web dannoso nel dominio attaccato (ad esempio, su una workstation in Windows2000 dominio, tutte le workstation si trovano anche nel dominio DNS);

utilizzo di un attacco di partizionamento della risposta HTTP.

Vale anche la pena notare qui che un attacco di sessione di commit a lungo termine può essere eseguito dall'emissione di cookie persistenti (ad esempio, con una durata di 10 anni) che manterranno la sessione di commit anche dopo il riavvio dell'utente del computer. Ecco un esempio:

http://example/<script>document.cookie="sessionid=1234;%20Expires=Friday,%201-Jan2017%2000:00:00%20GMT";</script>.idc

Sessione di avvelenamento (Session Poisoning).

La minaccia di una sessione avvelenata si verifica se un utente malintenzionato ha la possibilità di installare il proprio script PHP sul server in cui viene eseguita l'applicazione attaccata. L'essenza dell'attacco è che se le applicazioni PHP vengono eseguite sullo stesso server, è probabile che, conoscendo l'ID della sessione, l'attaccante possa lavorare con i dati della sessione creati nell'applicazione attaccata. L'avvelenamento è possibile se l'applicazione attaccata ha un bug che consente l'esecuzione di codice arbitrario e se l'applicazione Web è in esecuzione sul server insieme alle applicazioni di altri utenti di hosting.

L'obiettivo di questo attacco è ottenere l'accesso ai valori di sessione in lettura / scrittura. In caso di successo, l'attaccante sarà in grado di leggere e/o falsificare qualsiasi valore memorizzato nella sessione. Gli avvelenamenti vengono utilizzati per ottenere i dati personali di altri utenti, nonché per modificare la propria sessione, impersonare e/o elevare i privilegi.

Ecco l'esempio più semplice di questo attacco:

$var = $_GET["something"];

$_SESSION["$var"] = $var2;

Autenticazione tramite moduli.

Quando un client accede a una pagina e inserisce un login e una password, le sue credenziali vengono trasferite al server. Nel caso in cui l'autenticazione abbia esito positivo, il server genera un ticket di sessione per questo utente e in tutte le successive chiamate al server viene già utilizzato questo ticket, i cui dati vengono memorizzati in un cookie. Per impostazione predefinita, la durata del biglietto è di 30 minuti. Al termine di tale orario, il biglietto può essere rinnovato automaticamente. Nel caso in cui non ci siano stati più accessi entro un certo intervallo di tempo, il server invia al client un messaggio con la richiesta di «dimenticare» questo ticket, a seguito del quale il browser elimina questo cookie e l'utente deve reinserire le credenziali per accedere.

Sembrerebbe che tutto sia abbastanza logico e corretto. Ma il client (o meglio, l'attaccante) può periodicamente chiedere al server di rinnovare il proprio biglietto, essenzialmente un numero illimitato di volte. Cioè, il server non controlla il numero di volte in cui il biglietto è stato rinnovato. E un utente malintenzionato potrebbe semplicemente ignorare l'offerta ricevuta dal server di «dimenticare» il proprio biglietto e continuare a rinnovarlo ulteriormente.

In questo modo, se un utente malintenzionato è stato in grado di rubare il cookie del ticket, sarebbe in grado di utilizzare la sessione utente.

Cross Site Request Forgery.

Il buon vecchio CSRF è rilevante anche per .NET. ricordiamo che CSRF è un tipo di attacco ai visitatori del sito Web che sfrutta i difetti del protocollo HTTP. Se la vittima accede a un sito creato da un utente malintenzionato, viene segretamente inviata una richiesta a un altro server (ad esempio, un server del sistema di pagamento) che esegue una sorta di operazione dannosa (ad esempio, il trasferimento di denaro sul conto dell'utente malintenzionato).

Diverse condizioni devono essere soddisfatte per eseguire questo attacco. Innanzitutto, la vittima deve essere autenticata sul server su cui viene eseguita la richiesta. Anche questa query non dovrebbe richiedere alcun

conferme da parte dell'utente che non possono essere automatizzate, ovvero che non possono essere manomesse dallo script attaccante.

Ad esempio, considera la situazione in cui un utente accede utilizzando l'autenticazione basata sugli stessi moduli di cui abbiamo parlato un po ' prima. Il server esegue l'autenticazione dell'utente e fornisce una risposta che include il ticket dell'utente nel cookie. Allo stesso tempo, il sito web della Banca si fida di qualsiasi richiesta che riceve con un biglietto valido nel cookie. Successivamente, l'utente, senza terminare forzatamente la sessione sul sito web della Banca, visita un altro sito, www.hacker.com che contiene un modulo HTML in cui è nascosto l'invio nel modulo dei seguenti dati:

</form>

Tieni presente che il modulo invierà i dati al sito web della banca. Questa è la parte» cross-site " di CSRF. Quindi, con qualsiasi pretesto, all'utente viene chiesto di fare clic su un pulsante che invierà segretamente i dati del modulo. Quando si invia il modulo, il browser invierà automaticamente un biglietto nel cookie per il dominio richiesto, perché l'utente è ancora formalmente registrato sul sito web della banca. Di conseguenza, la richiesta verrà eseguita sul sito web della banca. Vale la pena notare che L'utilizzo di HTTPS non impedisce gli attacchi CSRF. Un sito dannoso può inviare una richiesta con la stessa facilità di una richiesta non sicura.

Tali attacchi sono resi possibili dal fatto che il browser memorizza i cookie emessi dall'Applicazione, Questi cookie contengono anche i ticket di sessione degli utenti autenticati e infine il browser invia all'applicazione Web tutti i cookie relativi al dominio, indipendentemente dal modo in cui la richiesta all'applicazione è stata creata nel browser.

Oleg Petukhov, avvocato nel campo del diritto internazionale e della protezione dei dati personali, specialista nel campo dell'informazione sicurezza, protezione delle informazioni e dei dati personali.

Canale Telegram: https://t.me/protezionedelleinformazioni

Gruppo in telegramma: https://t.me/protezionedelleinformazioni1

Sito: https://legascom.ru

E-mail: online@legascom.ru

#protezionedelleInformazioni #sicurezzadelleinformazioni

Написать нам...