игровая рамка owasp топ 10 - PullRequest
30 голосов
/ 17 июня 2011

Я подумываю об использовании Play для крупномасштабного проекта, так есть ли кто-нибудь испытанный в боевых условиях игровой фреймворк для OWASP Top 10?Есть ли какие-либо проблемы с безопасностью, которые вы знаете в Play Framework?

Ответы [ 2 ]

41 голосов
/ 17 июня 2011

В OWASP Top 10 и Play (немного информации здесь ):

  • A1: впрыск

    Использует JPA и экранирует строки по умолчанию

  • A2: межсайтовый скриптинг (XSS)

    Начиная с версии 1.0.1, движок шаблонов Play автоматически экранирует строку

  • A3: сломанная проверка подлинности и управление сеансами

    Игра без сохранения состояния, без участия сеанса. Файлы cookie защищены криптографией. Безопасное хранение данных в базе данных (пароли) с помощью хеширования зависит от пользователя, а не от структуры

  • A4: небезопасные ссылки на прямые объекты

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

  • A5: Подделка межсайтовых запросов (CSRF)

    POST-запросы позволяют токены аутентификации предотвратить это. Конечно, это зависит от того, как разработчик правильно использует GET / POST

  • A6: неправильная настройка безопасности

    По умолчанию процесс создания отчетов об ошибках безопасен (без утечек из трассировки стека). Единственной проблемой будет запись «поймать все» на маршрутах, но это должно быть закомментировано в производственном режиме

  • A7: небезопасное криптографическое хранилище

    Разработчик несет ответственность за шифрование разумной информации в базе данных

  • A8: сбой при ограничении доступа к URL

    Разработчик должен внедрить ограничение безопасности (через @Before, как в учебнике), чтобы запретить доступ к запрещенным страницам.

  • A9: недостаточная защита транспортного уровня

    Play поддерживает SSL

  • A10: Непроверенные перенаправления и пересылки

    Переадресация воспроизведения осуществляется через 302, а не в жестко заданных строках, что должно предотвратить это.

TL; DR: в тех частях, где фреймворк может выполнять всю работу, Play делает это. В частях, которые разработчик должен сделать всю работу, ну, разработчик должен сделать всю работу. Части, которые нуждаются в 50% каждой, Play дает свои 50%.

Давайте скажем так: нет причины, по которой вы должны считать Play менее безопасным, чем любая другая среда Java. Во многих случаях вы можете считать это более безопасным. А благодаря тому, что Play является простой для разработчика средой без REST и REST, у вас меньше шансов запутаться.

5 голосов
/ 18 марта 2014

Насчет А3, нужно быть осторожным.Play имеет два типа переменных сеанса.Один из них session(), который имеет цифровую подпись, а другой flash(), который не подписан.Также оба из них хранятся в файлах cookie на стороне клиента , что может вызвать проблемы с конфиденциальностью, если вы решите хранить там конфиденциальные данные.

Также, что касается A7 (криптография), обратите внимание, что Play предлагает удобную библиотеку Crypto, но ее шифрование использует режим ECB, который снова открывает целую новую группу потенциальных проблем .

...