Причём что самое интересное — buy orders есть уже по цене 0.00005 BTC за MOTO. Это означает, что поиграв в игру пару часов (а при хороших скиллах — около 20 минут), и получив 10 раз вознаграждение по 100 MOTO, сейчас, теоретически, можно на полученное за майнинг вознаграждение приобрести 0,05 BTC, что по текущему курсу — около $25. Если бы мне сейчас было лет 14, то я бы всерьёз рассмотрел вариант использовать это как самый настоящий заработок. Не это ли мечта многих подростков — играть в компьютерные игры, ещё и получая за это деньги?
Теоретически, можно как-то автоматизировать процесс проверки «проходимости» уровня, и генерировать хоть по 100 уровеней в секунду, до тех пор, пока не будет найден такой, который алгоритм счёл достаточно простым.
Веб-разработчик. Более 11 лет опыта программирования (начиная с 2011 года — в том числе на позиции тимлида).
Python/Django, на фронтэнде валидный HTML5, CSS3, JavaScript/jQuery. Понимаю, как сделать хороший и удобный для пользователя интерфейс. Также имею опыт в области компьютерной безопасности, системного администрирования, технического перевода и написания технической документации.
Как-то раз я уже обращал внимание специалистов mail.ru, что они не доставляют сообщения пользователям сайта Background Dating, принося им таким образом определённые неудобства (не могут сбросить пароль на сайте и так далее — я им поэтому пока что рекомендую ставить другую почту, если они обращаются в техническую поддержку).
К сожалению, мне тогда так ничего и не ответили. А теперь получается, что реджектятся письма у кучи сайтов (не просто падают в спам, что может быть и на GMail, и на Яндекс.Почте, а именно отбрасываются). Фу такими быть.
Кстати, лично проверял два сервера в прошлом месяце — оба оказались в безопасности как раз из-за того, что на одном была версия 1.0.0j-fips 10 May 2012, а на другом вообще 0.9.8k 25 Mar 2009. Ни ту, ни другую версию OpenSSL уязвимость CVE-2014-0160 не затрагивает.
Мне вообще кажется, что отказывать пользователю в возможности использовать ваш сайт только из-за того, что его браузер настроен на то, чтобы не отсылать referer (или отсылать определённый) — не слишком корректно.
И да, проверка referer — вообще так себе защита от CSRF, скажем прямо.
А вообще на современных сайтах куча клиентской информации (ручное перезаписывание которой не приведёт ни к каким негативным последствиям) хранится, например, в local storage в браузере. По-моему, совершенно прекрасная возможность — если какие-то клиентские данные не нужны на сервере, так пускай локально и хранятся. И, опять же, загрузку так можно ускорить, записав туда что-то, что иначе нужно было бы каждый раз запрашивать по сети.
Вам — ничего не мешает. А пользователю, которого хочет перенаправить сайт, на который вы ссылаетесь, мешает отсутствие понимания того, как это сделать (потому что если бы оно присутствовало, то он был бы не из тех, кого вообще можно обмануть таким образом).
Итак, описываю суть ещё раз.
У вас на сайте ссылка с target="_blank". Ссылка ведёт на сайт Иосифа Александровича. Пользователь щёлкает на ссылку, открывается новая вкладка. В то же время, в новой вкладке загружается сайт Иосифа Александровича, на котором запускается JS-код, который меняет window.opener.location. В результате в той вкладке, в которой был ваш сайт, теперь что-то совсем другое — может, например, страница, которая выглядит точно так же. Пользователь, теоретически, может это и не заметить, потому что он не привык, что открываемый сайт может менять страницу в той вкладке, из которой этот сайт открыли.
Помимо того, что это раздражает пользователей, вы предоставляете стороннему сайту доступ к вашей странице через объект window.opener. На эту тему в начале прошлого года ещё здесь писали.
В частности, вы можете поменять адрес страницы через window.opener.location. Прекрасная возможность для фишинга. Кстати, работает в том числе и с Google (у него тоже такие ссылки).
Проверять заголовок Host, не отдавать сайт, если в нём что-то неожиданное (другой hostname). Отдавать в таких случаях, например, HTTP 444 или HTTP 302 (и нормальный адрес сайта в Location).
Добавлять заголовок X-Frame-Options.
Проверять crossdomain.xml в корне сайта.
Никогда не добавлять ссылки с target="_blank", ведущие на сторонний сайт (если это необходимо — указывайте в href ссылки внутренний адрес, с которого будет происходить перенаправление на нужную страницу стороннего сайта).
В Django так сделано по крайней мере по двум причинам:
Разграничение доступа — в ряде случаев доступ к редактированию шаблонов есть у относительно широкого круга лиц. Соответственно, необходимо, чтобы управлять отображением чего-либо на сайте эти люди могли, но вот выполнять произвольный Python-код — нет. При этом с Django поставляется, например, тэг ssi (чтение любого файла в шаблоне), но чтобы использовать его с каким-либо файлом, одна из родительских директорий должна быть указана в настройке ALLOWED_INCLUDE_ROOTS. То есть, как видите, по умолчанию всё сделано так, чтобы из шаблонов можно было делать только то, что необходимо в шаблонах, а не что угодно.
Предполагается, что есть бэкэнд-разработчики, а есть фронтэнд-разработчики. Соответственно, фронтэнд-разработчики, которые не знают Python, таким образом получают возможность самостоятельно писать шаблоны.
Вот почему люди должны подстраиваться под финансовое законодательство, а не наоборот? По-моему, это законодательство ущербно, если не позволяет без «хаков» заниматься честными и общественно полезными вещами, не наносящими вреда другим людям.
Python/Django, на фронтэнде валидный HTML5, CSS3, JavaScript/jQuery. Понимаю, как сделать хороший и удобный для пользователя интерфейс. Также имею опыт в области компьютерной безопасности, системного администрирования, технического перевода и написания технической документации.
Более подробно вот здесь.
E-mail: aruseni@ya.ru
Просто откройте Фаербаг, и уберите у поля (тэг input) атрибут «onpaste».
К сожалению, мне тогда так ничего и не ответили. А теперь получается, что реджектятся письма у кучи сайтов (не просто падают в спам, что может быть и на GMail, и на Яндекс.Почте, а именно отбрасываются). Фу такими быть.
И да, проверка referer — вообще так себе защита от CSRF, скажем прямо.
А вообще на современных сайтах куча клиентской информации (ручное перезаписывание которой не приведёт ни к каким негативным последствиям) хранится, например, в local storage в браузере. По-моему, совершенно прекрасная возможность — если какие-то клиентские данные не нужны на сервере, так пускай локально и хранятся. И, опять же, загрузку так можно ускорить, записав туда что-то, что иначе нужно было бы каждый раз запрашивать по сети.
Итак, описываю суть ещё раз.
У вас на сайте ссылка с target="_blank". Ссылка ведёт на сайт Иосифа Александровича. Пользователь щёлкает на ссылку, открывается новая вкладка. В то же время, в новой вкладке загружается сайт Иосифа Александровича, на котором запускается JS-код, который меняет window.opener.location. В результате в той вкладке, в которой был ваш сайт, теперь что-то совсем другое — может, например, страница, которая выглядит точно так же. Пользователь, теоретически, может это и не заметить, потому что он не привык, что открываемый сайт может менять страницу в той вкладке, из которой этот сайт открыли.
В частности, вы можете поменять адрес страницы через window.opener.location. Прекрасная возможность для фишинга. Кстати, работает в том числе и с Google (у него тоже такие ссылки).
Добавлять заголовок X-Frame-Options.
Проверять crossdomain.xml в корне сайта.
Никогда не добавлять ссылки с target="_blank", ведущие на сторонний сайт (если это необходимо — указывайте в href ссылки внутренний адрес, с которого будет происходить перенаправление на нужную страницу стороннего сайта).