| WikiProject Компьютерная безопасность / Вычислительная техника | (Номинальный стартовый класс, высокая важность) | ||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| |||||||||||||||||||||
| WikiProject Интернет | (Номинальный начальный класс, средняя важность) | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| |||||||||||||
Файлы cookie [ править ]
Файлы cookie были «на домен» с тех пор, как Netscape представила их. Это тоже пример «политики одного происхождения»? - AndersFeder 16:53, 23 февраля 2007 г. (UTC)
Я вижу файлы cookie, установленные http://192.168.1.128:9000, которые отправляются на http://192.168.1.128:8000 как в FF4.0, так и в Chrome. Это нормально? Есть ли у файлов cookie исключение из Политики одинакового происхождения? Следует ли это четко указать на главной странице? Крис Дью 9:53, 14 июня 2011 г. (GMT)
@chrisdew. Крис Дью: Это объясняет, что одному источнику разрешено отправлять информацию другому источнику, но одному источнику не разрешается получать информацию от другого источника. Это может объяснить вам ситуацию. http://www.w3.org/Security/wiki/Same_Origin_Policy .-- рогоз ( разговор ) 13:00, 11 октября 2014 г. (UTC)
Порт [ править ]
Ранее в статье говорилось, что Internet Explorer не обращает внимания на порт. Однако в моих тестах Internet Explorer обращает внимание на порт. Возможно, установка document.domain обходит это; однако установка document.domain также обходит ограничения одного и того же домена, поэтому было бы несправедливо утверждать, что IE заботится о доменах, а не о портах. Rulesdoc ( разговор ) 23:17, 2 апреля 2008 (UTC)
Преодоление ограничения доступа [ править ]
Политика одинакового происхождения не применяется к файлам HTML, запускаемым из локальной файловой системы. Это позволяет локально запускаемому HTML-файлу, например, выполнять любой заданный HTTP-запрос.
Из моего эксперимента (firefox 1.0.7, IE5) html-файлы, запущенные в локальной файловой системе, могут выполнять HTTP-запрос, но не могут получить доступ к данным, возвращаемым из этого запроса. Более того, html-файлы, запущенные не локально, по-прежнему могут выполнять любой HTTP-запрос, но просто не могут получить доступ к данным. - Ans ( ток ) -Preceding комментарий был добавлен в 09:28, 9 мая 2008 (UTC)
Угроза [ править ]
В тексте статьи неясно, кто подвергается риску. Предположим, пользователь B запускает браузер и посещает веб-сайт C, содержащий JavaScript, который пытается получить доступ к сайту D. Кто проигрывает и что теряется, если доступ разрешен? Какой гнусный конец может достичь автор сайта C в этом сценарии, чего он не может достичь, напрямую обращаясь к сайту D.
Предварительный ответ: вредоносный JavaScript может отправлять сообщения на сайт D, которые кажутся D, как если бы они были вызваны действием B. Это происходит из-за файлов cookie, сохраненных в браузере из-за предыдущих действий сайта D, которые браузер включает в поддельное сообщение от программы JavaScript. Таким образом, программа JavaScript работает с полномочиями B и злоупотребляет ими! Это заставляет сайт D интерпретировать сообщение как сообщение, исходящее от действия B. Это плохо, если D - банк, а B - клиент банка. Сообщение может быть создано таким образом, чтобы деньги со счета B переводились косвенно на счет C.
Есть ли угрозы помимо злоупотребления файлами cookie? NormHardy ( разговор ) 22:10, 1 ноября 2008 (UTC)
Та же политика происхождения защищает многие другие ресурсы сайта, помимо файлов cookie, такие как сеансы с аутентификацией HTTP, сохраненные пароли и API localStorage. Он защищает конфиденциальность файловой системы из Интернета. В сочетании с HTTPS он может защитить от сетевых злоумышленников. Он используется в качестве строительного блока для защиты от подделки межсайтовых запросов и защиты от мошенничества с кликами. Он защищает целостность страницы, которую я просматриваю из других вкладок, которые я могу открыть, которые могут захотеть ее испортить - например, гарантируя, что пароли, которые я ввожу в формы входа, отправляются в правильное место. Rulesdoc ( разговор ) 06:02, 3 ноября 2008 (UTC)
Следующая статья дает хорошее объяснение модели угроз: http://blogs.msdn.com/b/ieinternals/archive/2009/08/28/explaining-same-origin-policy-part-1-deny-read. aspx - предшествующий беззнаковый комментарий, добавленный 50.83.15.223 ( обсуждение ) 23:43, 29 августа 2011 г. (UTC)
Основные изменения [ править ]
Я взял на себя смелость переделать большую часть статьи, включая удаление несвязанных или неверных данных (например, предположение о том, что зоны безопасности заменяют проверки на одно происхождение, упоминание о том, что браузеры могут быть изменены для обхода политики, или излишне подробное обсуждение XSRF), улучшив часть оставшегося текста (например, неточное объяснение поведения document.domain или переформулировку текста, подразумевающего, что контекст безопасности получен из того места, где был создан скрипт, а не страницы, на которой он был запущен). Дайте мне знать, если я забил его слишком много, но, похоже, так он будет более читаемым. Ссылки должны подтверждать большинство сделанных утверждений, поэтому я не стал беспокоиться о слишком большом количестве ссылок на утверждения, которые, как правило, легко проверить.
Я также удалил кучу избыточных ссылок и, полное раскрытие информации, подключил часть написанной мной работы - Руководство по безопасности браузера; единственная причина для этого заключается в том, что это почти наверняка наиболее полное, подробное и актуальное обсуждение политик одного и того же происхождения. Надеюсь, что все в порядке, если нет, не стесняйтесь возвращаться к старому дерьмовому набору или, еще лучше, найдите хорошую замену ;-) - lcamtuf ( обсуждение ) 19:08, 10 января 2009 г. (UTC)
"Одинаковый" vs. "Одинокий" [ править ]
Я думаю, что эта страница также должна отличаться от «Политики единого происхождения». Оба термина используются. Я бы добавил это, но не знаю, как это сделать. Патнимейер ( разговор ) 14:46, 18 марта 2009 (UTC)
- Очень хороший момент. Фактически, в настоящее время это «политика одного сайта», эта политика должна быть расширена до «политики одного источника». Итак, нам нужна спецификация «того же происхождения», то есть веб-приложение может иметь доступ к набору сайтов, а не только к одному отдельному сайту. Кроме того, это легко расширить. Пока браузеры могут это принять. Например, просто добавьте еще один атрибут к элементу ссылки в заголовке html, чтобы указать то же происхождение. Jackzhp ( разговор )
По соображениям безопасности хорошо подходит та же политика происхождения, но в настоящее время она реализована как политика единого сайта. Я думаю, что мы можем расширить defato «политику одного сайта» до аутентичной «политики одного и того же происхождения», то есть явно определить источник. Более конкретно, мы можем определить источник как набор URL-адресов (который указывает протокол, хост и порт). Jackzhp ( разговор ) 00:06, 26 июня 2011 (UTC)
«В двух словах» лишний [ править ]
На мой взгляд, излишне говорить «в двух словах» - это утверждение встречается в первом абзаце статьи, который по определению является резюме или абзацем «в двух словах».
Карл Грегори Джонс ( разговорное ) 00:18, 18 марта 2010 (UTC)
URL EasyXDM в статье [ править ]
http://easyxdm.net/wp/
Этот URL-адрес жестко встроен в статью, что неуместно. Кто бы это ни сделал, добавьте статью или сделайте ссылку, если easyXDM заслуживает внимания.
Внешние ссылки принадлежат этому разделу или ссылкам.
Или я ошибаюсь? Дж. Роберт Шиплет, 00:44, 16 июля 2011 г. (UTC)
Подготовка JavaScript -> Включить скрипты в разные домены [ править ]
В статье говорится:
- ... многие устаревшие междоменные операции, предшествующие JavaScript , не подвергаются проверкам на одно происхождение; один из таких примеров - возможность включать скрипты в разные домены ...
Я не понимаю, как включение скриптов в разные домены может считаться междоменной операцией, предшествующей JavaScript. Я что-то пропустил? Gilly3 ( разговор ) 00:39, 17 октября 2012 (UTC)
"Правила определения происхождения" Отсутствует информация [ править ]
Таблица и информация в этом разделе не поясняют какое-либо влияние на файлы (локально). Например, при использовании «file: /// C: /Location/a_file.htm» будут ли протоколы javascript запрещать что-либо происходить с любыми файлами вокруг него? скажите "file: /// C: /Location/another_file.htm"
Спасибо. - Предыдущий беззнаковый комментарий добавлен 98.237.13.239 ( обсуждение ) 09:40, 28 декабря 2012 г. (UTC)
Рассуждение [ править ]
В этой статье объясняется, как работает политика одинакового происхождения, а также как ее обойти, но не объясняется, для предотвращения каких проблем она была создана. Возможно, следует добавить раздел об этом? - 202.213.201.225 ( разговорное ) 09:51, 7 марта 2013 (UTC)
- Я согласен; в статье есть исключения, но на самом деле ей нужен пример того, к чему на самом деле применяется эта политика. - Беланд ( разговор ) 17:12, 9 июня 2014 (UTC)
Я добавил небольшую часть истории, чтобы объяснить общий эксплойт. Этого достаточно? 2015-11-18 - Предыдущий неподписанный комментарий добавлен Rocketpipe ( обсуждение • вклад ) 20:59, 18 ноября 2015 (UTC)
Раздел по вопросам безопасности [ править ]
Я добавил новый раздел, чтобы было понятно, о чем все это. В первом разделе (введение), втором абзаце, есть два предложения, в которых упоминается одно и то же (файлы cookie HTTP, пользовательские сеансы, конфиденциальная информация, действия по изменению состояния), но немного запутанные и очень короткие. Пользователи, читающие это, вероятно, не поймут этого из этой короткой части, поэтому я добавил новый раздел. Не стесняйтесь объединить два. Но я бы предпочел расширить новый раздел некоторыми рисунками блок-схем и другими примерами. Политика одинакового происхождения - это то, что затрагивает многих разработчиков, и они просто думают, что это ерунда, или просто разрешают заголовки CORS для всех, поэтому важно полностью понять риски, особенно если разработчики могут сначала обратиться к Википедии. - 165.222.185.144 ( Обсуждение) 18:27, 23 марта 2016 г. (UTC)
Могу ли я добиться успеха [ править ]
Вы все поможете мне, пока я не разберусь с этим Stevo47 ( разговор ) 06:08, 14 ноября 2017 г. (UTC)
«Скрипты» против других ресурсов против ответов XHR [ править ]
Слова «очень важно помнить» вызвали во мне википедию как своеобразное исследование . Кроме того, упущен пункт СОП. Я считаю, что SOP не позволяет javascript источника пользовательского интерфейса читать встроенные ресурсы (за исключением некоторых метаданных, таких как размеры изображений) и ответы XHR из источников. Кроме того, я думаю, что SOP не препятствует отправке данных из разных источников. Кроме того, я думаю, что у SOP может быть недостаток, позволяющий читать и изменять глобальные переменные, используемые во встроенных скриптах с перекрестным происхождением. - ilgiz ( разговор ) 14:39, 29 мая 2019 (UTC)
