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

На мой взгляд брандмаузер должен выглядеть как то так: image
Извините за оффтоп.
Во-первых, это кобура.
Во-вторых, лёгким движением пистолет превращается в карабин (которым, по существу, и является).
В-третьих, маузер C96 — тяжёлый и мощный, прицельно стрелять с рук проблематично.
Это же маузер. С его убойностью без такого приклада стрелять чистый мазохизм и показуха.
Отдача у C96 как раз небольшая. Патрон как у ТТ, вес больше, следовательно отдача — меньше.
Даже, если не затрагивать вопросов безопасности, картинки с внешних ресурсов — зло хотя бы потому, что:
1. Они имеют обыкновение удаляться с внешних ресурсов и на вашем ресурсе будут дыры в этом случае.
2. Через некоторое время картинка няшного котика может быть подменена внешним ресурсом на картинку с рекламой, например, наркоты. В этой ситуации вы, во-первых, понесете репутационные потери, а, во-вторых, можете нарваться на блокировку.
Именно. Например большинство старых статей на хабре с мертвыми картинками. И на известном трекере в любой раздече старше полугода нет скриншотов.
а затем не закрывая вкладок отключит VPN и прокси его IP будет у нас в кармане.

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

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

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

А касательно защиты профилями от CSRF это тоже самое что и разлогиниваться на сайте перед тем как заходить на другие, или же держать все развлекательные сайты в отдельном браузере. Не является защитой. Сложно провесит CSRF против сервиса, если ты на нем не авторизован.
Так Firefox же, может держать несколько профилей и режим инкогнито одновременно. Очень удобно:
firefox -p  -no-remote
Статья в целом интересная, кое-что новое почерпнул. Но название статьи и её содержимое не соответствуют друг другу.

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

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

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

Для этого используются самописные сервера — это заметно удобнее, можно использовать любой уровень OSI, управлять несколькими соединениями из одного приложения и тратится меньше системных ресурсов.
есть еще одна полезная штука, которую вы не упомянули — утечки ДНС
хорошо отлавливать прокси, т.к. на практике люди их использующие очень часто делают резолв доменов напрямую (в FF, например, по дефолту резолв доменов через прокси отключен)
Точно, спасибо. По этой теме наверное надо писать отдельно и тестировать возможные ситуации на нескольких хостах — DNS не такая простая вещь, запросы посылаются не напрямую и кэшируются на промежутке.
С кешированием нет проблем.
Тема очень широкая, но в случае картинок при проходе через цепочку редиректов на первом редиректе можно собрать основные данные и присвоить ид запросу, далее средиректить на уникальный субдомен 1234.example.com (1234 — ид запроса)

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

<!-- 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.
Only those users with full accounts are able to leave comments. Log in, please.