Картинки с внешних ресурсов — добро или зло?

[Coolfly]

Определение использования брандмаузера (Для Win)

На мой взгляд брандмаузер должен выглядеть как то так:
Извините за оффтоп.

[kaichou]

А зачем пистолету такой приклад?

[nickolaym]

Во-первых, это кобура.
Во-вторых, лёгким движением пистолет превращается в карабин (которым, по существу, и является).
В-третьих, маузер C96 — тяжёлый и мощный, прицельно стрелять с рук проблематично.

[DIHALT]

Это же маузер. С его убойностью без такого приклада стрелять чистый мазохизм и показуха.

[dimview]

Отдача у C96 как раз небольшая. Патрон как у ТТ, вес больше, следовательно отдача — меньше.

[Dolios]

Даже, если не затрагивать вопросов безопасности, картинки с внешних ресурсов — зло хотя бы потому, что:
1. Они имеют обыкновение удаляться с внешних ресурсов и на вашем ресурсе будут дыры в этом случае.
2. Через некоторое время картинка няшного котика может быть подменена внешним ресурсом на картинку с рекламой, например, наркоты. В этой ситуации вы, во-первых, понесете репутационные потери, а, во-вторых, можете нарваться на блокировку.

[klubben]

Именно. Например большинство старых статей на хабре с мертвыми картинками. И на известном трекере в любой раздече старше полугода нет скриншотов.

[shanker]

а затем не закрывая вкладок отключит VPN и прокси его IP будет у нас в кармане.

Это при условии, что после отключения VPN у него произойдёт замена шлюза по-умолчанию на шлюз его провайдера. Этим грешат некоторые VPN-сервисы, предоставляя соответствующие скрипты восстановления шлюза по-умолчанию при исчезновении tun.
Если же чел грамотный, то при исчезновении tun шлюз по-умолчанию у него так и останется VPN-овский. Т.е. никакого «его IP будет у нас в кармане» не произойдёт — у него тупо не будет инета и он не сможет подгрузить ваш ресурс. Так что «не так страшен чёрт», как тут написано

[Veratam]

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

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

[shanker]

Не всегда можно отделять эти понятия. В конфиге некоего VPN-провайдера есть скрипт, который отрабатывает в случае «if down interface». И в этом случае восстанавливает шлюз по-умолчанию на реальный шлюз провайдера. Типа, на тот случай, если пользователь сам отрубился от VPN.
Но штука в том, что «if down interface» происходит также при потере коннекта к VPN-сервису, что уже раскрывает анонимность. Именно в этом случае Ваш способ срабатывает.

Но всё равно спасибо за уточнение.

[tkf]

немного не по теме, но может вы знаете какой нибудь браузер с несколькими профилями с которыми можно работать параллельно? На манер того как в хроме есть обычный режим и инкогнито. Вот было бы неплохо несколько обычных режимов держать параллельно. Запуск хрома с разными параметрами из консоли а) не слишком удобен б) как то не слишком стабилен, по непонятным причинам.

А касательно защиты профилями от CSRF это тоже самое что и разлогиниваться на сайте перед тем как заходить на другие, или же держать все развлекательные сайты в отдельном браузере. Не является защитой. Сложно провесит CSRF против сервиса, если ты на нем не авторизован.

[Veratam]

Так Firefox же, может держать несколько профилей и режим инкогнито одновременно. Очень удобно:

firefox -p  -no-remote

[shanker]

Статья в целом интересная, кое-что новое почерпнул. Но название статьи и её содержимое не соответствуют друг другу.

Название статьи: «Картинки с внешних ресурсов — добро или зло?»

Часть содержимого: " по умолчанию TTL в Linux равен 64, в Windows — 128. Такие большие различия помогут определить OS удаленного хоста в некоторых случаях. "

Может, стоит мух отдельно, а котлеты — отдельно? Или я чего не знаю, и есть способ выяснить TTL приходящего от клиента пакета на уровне веб с помощью картинки, подгружаемой на веб-сервер со стороннего веб-ресурса?

[Veratam]

Вы имеете ввиду использование скриптовых языков за веб-сервером, например PHP?

Для этого используются самописные сервера — это заметно удобнее, можно использовать любой уровень OSI, управлять несколькими соединениями из одного приложения и тратится меньше системных ресурсов.

[baadf00d]

есть еще одна полезная штука, которую вы не упомянули — утечки ДНС
хорошо отлавливать прокси, т.к. на практике люди их использующие очень часто делают резолв доменов напрямую (в FF, например, по дефолту резолв доменов через прокси отключен)

[Veratam]

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

[baadf00d]

С кешированием нет проблем.
Тема очень широкая, но в случае картинок при проходе через цепочку редиректов на первом редиректе можно собрать основные данные и присвоить ид запросу, далее средиректить на уникальный субдомен 1234.example.com (1234 — ид запроса)

Из недостатков метода — сравнительно сложная реализация т.к. надо допиливать ДНС сервер и связывать его с основным сборщиком данных. Не так чтоб очень сложно, но заметно труднее, чем собирать хидеры и куки.

[relgames]

Интересно, а как работает whoer.net? Каким образом он определяет DNS?

[dasm32]

Примерно так и работает.

<!-- DNS unique domain -->
<tr>
<td align="left" class="wtl_z"><strong>DNS</strong></td>
<td colspan="3" class="wtr_z"><span id="dns_unique_domain"><span class="disabled">N/A</span></span></td>
</tr> 

<script language="javascript">
flash_ajax_request( "dns_unique_domain", "/dns?domain=oowia4181853.br" );
</script>
<link rel="stylesheet" type="text/css" media="all" href="HTTP://oowia4181853.br.whoer.net/css/null.css"> 

DNS при резолве отдаёт «No such name», но это неважно, запрос ведь уже прошёл. Оканчивается на ns55.dnlayer2.com/ns77.dnlayer2.com. Затем по GET-запросу на whoer.net/dns?domain=oowia4181853.br отдаётся IP.

[dasm32]

И да, «уникальный домен» приходит прямо в HTML-e.