технический блог: web

Как происходит такая атака рассказанно в Ruby on Rails Security Guide, возьму от туда лишь картинку иллюстрирующую процесс атаки:

Предотвратить такую атаку в классическом (не ajax) приложении можно только одним мало приятным способом – дописывать к каждый ссылке и к каждой форме параметры с токеном. В случае ajax приложения мы можем сделать защиту более удобной – без лишних токенов в ссылках.

Как это устроено?
Мы добавляем к каждому запросу заголовок X-CSRF-Token и проверяем этот токен классическим путем.
Передаем токен от сервера клиенту в виде куки, а при ajax запросе просто добавляем его к заголовкам. Кука действительна только в рамках домена, поэтому у нас её не утащат (надеемся что других уязвимостей в нашем web-сервисе нет)

У нас есть 3 случая которые нужно проверять на стороне сервера:

1. Ajax запрос с верным токеном – всё ок, показываем страницу, выдаем новый токен
2. Ajax запрос с неверным токеном – шлем лесом (скорее всего левый ajax запрос с другого сайта)
3. НЕ-Ajax запрос

Последний случай требует специальной обработки, т.к. это именно img src=»..» или iframe src=»…», но так же это может быть первый вход в приложение или F5 или открытие ссылки в новой вкладке.
В случае если к нам пришел такой запрос я выполняю следующий код:

if (preg_match('/\?/i',$_SERVER['REQUEST_URI'])){
$token = "&csrf_token=".$token;
}else{
$token = "?csrf_token=".$token;
}
$url = $_SERVER['REQUEST_URI'].$token;
echo "
-html
-body
Loading....
-script type='text/javascript'
if (parent.document.location.href == document.location.href){
document.location.href='".$url."';
}
-/script
-/body
-/htm;
";
die;

Что он делает (сорри форматер в блоге сломался)? Он выполняет js. о! в теге img js не выполнитсья!
На случай iframe мы проверяем parent.document.location.href == document.location.href – если это iframe – то редирект не произойдет.
Нам осталось только дописать что если токена нет в заголовках, будем ждать его в $_GET.

Таким образом мы защитились от CSRF лучше других: мы не только не даём делать действия, но и не даем узнать информаию пользователя (обрубается любой запрос без токера), мы защищаемся не только от дургих доменов, но и от своего если у нас найдут XSS и воткнут туда img src=’..’ или iframe src=»..» оно злоумышленику не поможет.

Всем удачи!

В дефотлином конфиге config/environments/production.rb написана строчка:
config.cache_classes = true
а она не совместима с опцией конфигурации unicorn:
preload_app true

поэтому одну из этих опций надо ставить в false – и загадочные падения прекратятся.

Примеры таких падений:
undefined method `each’ for nil:NilClass
mysql2 (0.2.6) lib/active_record/connection_adapters/mysql2_adapter.rb:635:in `select’

по прочие undefined method …. for nil:NilClass вылезающие рандомно )

Вот и настала пора обновить документацию к LynxCMS. Как я писал она доросла до версии 1.02 Beta. Составленная документация актуальна к 1.01 Alpha.

И кстати, а вы знаете какая бывает документация к таким продуктам? А вот следующая:

• Внутренняя документация разработчика
• Внутренняя документация о нагрузочных испытаниях
• Документация верстальщика – (как сверстать шаблон под LynxCMS)
• Документация разработчика – (как написать свой плагин/модуль/web-приложение) под LynxCMS
• Документация пользователя – (как этим всем пользоваться контент-менеджеру)

Предстоит большая работа по созданию скринкастов для пользователей, примеров кода для верстальщиков и пр.

Вот и вышли долгожданная версия моего сайта http://myConfig.ru.
К услугам добавилось оказание услуг рекламы, а хостинг потерпел большие изменения: поменялись тарифы, мы перенесли отдачу статики на nignx, а панелью управления стал ISPManager.

Всем радоваться полчиса!

Вот такой я нашел способ


<div style="border: 1px #000 solid; margin-right: 150px; padding: 2px; text-align: center; text-align: -webkit-center; text-align: -moz-center;"> <div style="border: 1px #f00 solid; display: table-cell; margin: 0 auto;">  item1 | item2 | item 3 </div></div>


работает везде, кроме IE6 (ну и фиг бы с ним )