В BSON-ruby был найден баг, который в лучшем случае приводил к небольшому DoS, но большинство версий было уязвимо к инъекции в BSON (аналог SQL инъекции, BSON это бинарный аналог JSON, используемый для работы с базой).

На хабре уже как-то упоминалась особенность регулярок в руби — у нас ^$ значат не просто начало и конец строки, но и новую строку \n.

Но тогда в примерах были лишь XSS «javascript:a()\nhttp://», и я давно искал пример, когда регулярки приводят к чему-то серьезному. И вот пару дней назад, во время аудита внешних библиотек нашего клиента, наткнулся на следующий код в BSON-ruby.

def legal?(str)
  !!str.match(/^[0-9a-f]{24}$/i)
end

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

Итак, не так давно мне в голову пришла идея купить 3 карты Старбакса по $5 каждая.

С помощью простого ввода ../sms можно было обойти второй фактор на сайтах использующих 2FA через authy.com (а их довольно много).

Самое интересное что такая досадная уязвимость появилась не по вине Authy, да и нашел я всю эту цепочку багов с большой удачей.

Все очень просто — если мы можем перелогинить пользователя в свой фейсбук то мы можем присоединить свой фейсбук к аккаунту жертвы на других вебсайтах. Жертва загружает нашу страничку и мы получаем доступ к аккаунту жертвы на Booking.com, Bit.ly, About.me, Stumbleupon, Angel.co, Mashable.com, Vimeo и куче других вебсайтов.

OpenURI в руби это стандартная библиотека сильно упрощающая работу с URL так как она объединяет в себе Net:HTTP/HTTPS/FTP и представляет из себя всего лишь метод open. Насколько я знаю это самый популярный способ для скачивания файла, GET запроса или чтения данных.

Но на деле require "open-uri" патчит Kernel.open и вызывает разный код для разных аргументов, что может привести к удаленному выполнению кода или чтению любого файла на сервере!

open(params[:url]) это выполнение кода для url=|ls Все что начинается с | рассматривается как системный вызов.

open(params[:url]) if params[:url] =~ /^http:// не лучше для url=|touch n;\nhttp://url.com (сломанные регулярки могут привести к RCE, используйте \A\z).

В последнее время появилась масса биткоин сервисов. И то что раньше было проектом «for fun» неожиданно стало хранить десятки и даже сотни тысяч долларов. Цена биткоина выросла, но уровень безопасности биткоин сервисов остался таким же низким.

Ради портфолио мы провели бесплатный аудит биткоин биржи с открытым кодом Peatio использующей Ruby on Rails. Репорт в pdf можно скачать тут. Самое интересное что в результате нашлись не очередные унылые рейс кондишены или SQLi, а довольно таки любопытная цепочка багов ведущая к угону аккаунта и краже существенной части горячего кошелька.

В первую очередь поясню что эта технология находится на ранней стадии разработки, и я бы хотел подискутировать в этом топике о её рентабельности и полезности. Поэтому прототипа еще нет.

Большинство уязвимостей в веб сайтах являются результатом изменения HTTP запроса, подмены URL или заголовков, и прочие неожиданные для сервера действия. Обычный пользователь не должен иметь возможности так делать, но так как современное приложение состоит из клиента и сервера, то в реальности сервер не имеет контроля над тем как пользователь использует клиентскую часть.

Из-за этого «двойная валидация» встречается повсеместно — на экране нужно показывать только объекты доступные пользователю, плюс нужно на сервере проверять имеет ли пользователь доступ к данному объекту.

Так возникла идея SecureCanvas — превратить сайт в подобие АТМ/терминала, где пользователь может только печатать и двигать мышку. Вместо попытки перехватить вредоносные запросы мы просто переводим игру в другую плоскость и снижаем поверхность атаки до нуля, разрешая пользователю делать лишь то что он и должен делать — взаимодействовать с сайтом.

Paperclip это самый популярный джем для загрузки файлов/аватарок в рельсах. В нем был найден довольно простой логический баг, ведущий к загрузке произвольного файла на сервер, то есть с произвольным extension: file.html, file.php, file.cgi и так далее.

Paperclip имеет «магическую» (как и все в рельсах) систему адаптеров. Если на входе объект типа File, то берется файловый адаптер, если строчка то сверяется по разным паттернам. Если строчка типа URL http://* то делается запрос по этому URL чтобы выкачать файл.

Это история о том, как я соединил 5 Low-severity багов в один большой баг, с помощью которого можно было читать/писать в приватные репы на Гитхабе (опять).

Несколько дней назад гитхаб запустил баунти программу. За 4 часа я смастерил такой URL после посещения которого я получал доступ к вашему гитхаб аккаунту и репозиториям. Хотите узнать как?

Есть такой специальный хедер для безопасности вебсайтов CSP.

CSP ограничивает загрузку каких либо ресурсов если они не были пре-одобрены в хедере, то есть отличная защита от XSS. Атакующий не сможет загрузить сторонний скрипт, inline-скрипты тоже отключены…

На уровне браузера вы можете разрешить только конкретные урлы для загрузки а другие будут запрещены. Помимо пользы этот механизм может принести и вред — ведь факт блокировки и есть детекция! Осталось только придумать как ее применить.

Это — сиквел моей сногсшибательной первой статьи.

Готов поспорить что каждый веб разработчик сталкивался с фейсбук коннектом или вконтакте логином или аутенфикацией через твиттер. Все это по сути построено на основе OAuth1/2.

Мое мнение заключается в том что мы все ступили не на ту дорожку. OAuth это дорожка в ад (к слову, Эран Хаммер сейчас работает над заменой oauth — oz).

В этой статье я не буду погружаться в модель атаки а перескажу совершенно конкретные уязвимости которые вы можете начать использовать прямо сейчас.

У jQuery есть встроенная фича — если сервер ответит с content-type=text/javascript библиотека выполнит ответ автоматически.

jQuery.ajaxSetup({
	accepts: {
		script: "text/javascript, application/javascript, application/ecmascript, application/x-ecmascript"
	},
	contents: {
		script: /(?:java|ecma)script/
	},
	converters: {
		"text script": function( text ) {
			jQuery.globalEval( text );
			return text;
		}
	}
}); 

Поэтому в рельсах довольно распространена тактика «ответь строчкой Javascriptа вместо правильного JSON, который придется обрабатывать».

Знаете ли вы, что субдомен sub.host.com может ставить куки для *.host.com? Наверняка, да.
А как много он может их поставить? Очень много.
А сколько браузер будет отправлять их впоследствии? Все!

А что получится, если «заспамить» главный домен своими куки-бомбами? На всей системе .host.com все запросы будут иметь супер длинный хедер Cookies, добавленный браузером, и эти запросы не будут обрабатываться сервером из-за слишком большого размера.

Попросту говоря, после посещения специальной страницы, вы не сможете заходить, например, на такие сайты: *.wordpress.com, *.github.io, ваша «экосистема» Гугла сломается, если я заспамлю .googleusercontent, а также не забываем про Content Delivery Network — заспамив главный домен network_name.net, все JS и стили, хранящиеся там, перестанут подгружаться!

Более того, вы можете «заспамить» так конкретный /dontlike путь, например пост конкурента на блогспоте/тумблере/вордпрессе.

Предлагаю обсудить, как можно исправить эту проблему.

Вкратце: Rails 2,3 и 4 приложения подвержены выполнению произвольного кода(RCE) без исключения. Шел, чтение и очистка базы данных, все что душе угодно.

У нас тут в Rails комьюнити опять драма. Первоначальный репорт. Есть методы типа find_by_* которые проецируются на модели в find_by_title например и find_by_id.
Их можно использовать так
find_by_id(params[:id], select: «CUSTOM SQL»)
Но обычно их используют вот так
find_by_id(params[:id])
И происходит SQL Injection если в params[:id] лежит {:select => «CUSTOM SQL»} — опции могут быть и в первом аргументе.

Обратите внимание — :select это символ а не «select»(строка). Это значит что трюк ?id[select]=SQL не пройдет т.к. ключ окажется строкой. И вообще params это хеш типа HashWithIndifferentAccess. Те у него ВПРИНЦИПЕ не может быть символов в ключах т.к. они все уничтожаются при создании.

Есть такой gem authlogic, в общем виде он использует find_by_token(token) где token это объект из сессии(которая хранится в куках и подписана session_secret). Чтобы в него записать :select => «SQL» вам нужно знать session_secret, поэтому уязвимость крайне редкая.
Весь этот SQL Injection CVE не стоит выеденного яйца! И ради чего пост? DoS!

Данная блогозапись на хабр прежде всего обусловлена появлением «Ключницы» — хороший повод связать и перевести накопленное.


У нас в программе: вольный пересказ спек OAuth2, слабые стороны и Threat Model, 0day на хабретрюк с аутенфикацией.

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

В рамках серии «Как Стать Успешным Рубистом». Оригинал.


Дирк-Ян Базинк(Dirkjan Bussink) опытный разработчик и активный участник Ruby сообщества. twitter.com/dbussink
github.com/dbussink

Дмитрий Белицкий провел 18 потрясных интервью с рубистами. А я решил их перевести и опубликовать тут.

ATTENTION: rezwyi.blogspot.com/search/label/%D1%81%D0%B5%D0%BA%D1%80%D0%B5%D1%82%D1%8B%20%D1%83%D1%81%D0%BF%D0%B5%D1%85%D0%B0 здесь остальные переводы от товарища Сергея Резванова.

Как стать успешным Рубистом?

Ответ на этот вопрос знают, скорее всего, успешные рубисты.

Я подготовил девять вопросов и задал их по Email людям, которые, по моему мнению, являются таковыми.

Geoffrey Grosenbach
Desi McAdam
Giles Bowkett
Dirkjan Bussink
Jamis Buck
Yehuda Katz
James Edward Gray II
Carlos Gabaldon
Fabio Akita
Pat Allan
Peter Cooper
Ryan Bates
Paul Campbell
Matt Aimonetti
Nathaniel Talbott
Elise Huard
Chris Wanstrath (defunkt)
Oleg Andreev (oleganza)

1 — переводы постараюсь публиковать по одному в день.
2 — рад любым корректировкам

Это всего-лишь идея для приложения, которое может быть полезно вам и мне. Нередко качая какую нибудь книгу в формате PDF решаешь её прочитать, скажем 2-3 страницы в день. И, разумеется, потом все это легко забываешь, еще легче чем если бы она была бумажная.
(Если проблем с силой воли у вас нет — поздравляю, дальше можете не читать)

Лично я очень часто читаю свой ридер. Я считаю своим долгом доводить количество непрочитанных записей до 0.

Идея такая — делается простое приложение на appspot.com(например), которое будет делить залитый файл (PDF/TXT) на кусочки — параграфы, затем пользователь сам указывает сколько ему нужно глав в день, и другие настройки.
Затем он получает ссылку на RSS, по которой он сможет читать свою книгу.

Готовых реализаций не нашел, но лично мне идея очень по-вкусу.