This report represents the analysis results for the specified source code. It contains features identified from a large variety of common characteristics including security and privacy characteristics, and other attributes to answer the question 'What is in the code?'.
Интересные идея и тула. Может помочь при ревью кода нового проекта. Это не замена SAST-решению, а скорее инструмент аудитору для быстрого понимания из чего (каких функциональных блоков) состоит проект.
Очень жаль, что GitLab не полноценный FOSS и практически все фишки про безопасность только в максимальных лицензиях. При том, что сам он активно использует FOSS решения для безопасности.
Джира впоне может тормозить на большом количестве проектов и задач
Часто в базе нет нужной функциональности (например, шаблоны в Джире) и предоставляется через плагины, которые опять же могут быть дорогими
Мелочи, которые могут оказаться не такими уж и мелочами для вас. В Конфлюенсе убрали вики-разметку и нет нормальных (friendly) URL для страниц, а Джире из коробки только (?) LDAP для SSO
Практически нет поддержки Markdown. В Конфлюенсе только импорт, а в Джире вообще своя plaintext-разметка
Коммерческие решения часто приподносятся как нетребующие штата для их поддержки. Так вот в компаниях со стеком Атлассиана, обычно как минимум пара человек на их поддержке.
Интересный вопрос! На сколько мне известно, между организациями сейчас нет какого-либо взаимодействия, к сожалению. При этом, конечно же, могут быть отдельные участники, которые состоят в обоих сообществах. Ну и у них немного разные активности и задачи: W3C — это про стандарты в вебе, в том числе, связанные с безопасностью. OWASP же скорее про повышение уровня безопасности приложений в рамках их разработки.
Меня OWASP всегда озадачивал дикой смесью очень полезных и практичных шпаргалок по безопасности против отдельных конкретных атак, и вот таких вот общих бесполезных документов.
Всё просто — это как теоретические основы в какой-нибудь области и практичные справочники.
«Проактивная защита: Топ-10 требований OWASP» как раз хорош кажущейся простотой и даже, возможно, банальностью. При этом в нём сделана хорошая попытка системно подать самые основы разработки безопасных веб-приложений.
В результате для большинства типичных проектов этот «серьёзный документ» вырождается в несколько банальных рекомендаций: проверяйте все данные на входе, экранируйте все данные на выходе, используйте TLS.
Парадокс в том, что за каждым из перечисленных выше пунктов скрывается «большая часть айсбергов». В том смысле, что, например, рекомендовать экранировать все данные без учёта существования контекстов их вывода будет недостаточно. И вообще экранировать или всё-таки кодировать? 0_о В проверках всех данных на входе тоже можно наделать ошибок, а уж сколько всего скрывается за «простым» использованием TLS…
«Проактивная защита: Топ-10 требований OWASP», «Top-10 OWASP», «OWASP SAMM» и те же шпаргалки — всё это попытки с разных сторон (и подходов) помочь разрабатывать в результате безопасные приложения.
Если это не троллинг, то, пожалуйста, перечитайте сам репорт и мой комментарий выше. Что касается размера награды, то она всё-таки вполне хорошая. И даже у самого исследователя каких-либо замечаний по её поводу не было, что видно, опять же, из репорта.
Ещё раз спасибо классную находку, а также за то, что опубликовали краткий пересказ нашего общения в репорте. Для того, чтобы у читателей сложилась полная картина, ещё раз продублирую ссылку на полный дисклоз. В вашем посте поднято, как минимум, два важных вопроса.
Первый, конечно же, о самой уязвимости. Мы, признаюсь, по-началу были скептично настроены, из-за того, что вдруг заполучили такую "классическую дыру". По классификации OWASP она относится к Top 10-2017 A5-Broken Access Control и является очень критичной. Всем рекомендуется ознакомится с её описанием и тем, как в следующий раз так "больно не выстрелить себе в ногу". Благодаря вашему упорству нам удалось докопаться до сути проблемы, а, исправив, мы конечно добавили юнит-тестов безопасности.
Второй поднятый вами вопрос касается общения между вендором и исследователем. В своё время инициатива багбаунти программ кардинально изменила ситуацию этого общения к лучшему и дала возможность "белым шляпам" легально искать уязвимости в сервисах, делая их таким образом безопаснее, а взамен ещё и получать вполне весомую благодарность от вендора. Тем не менее, нам ещё есть над чем работать! Быть более открытыми и вежливыми друг-другу и стараться говорить на одном языке (см. Google Bughunter University).
В ICQ вопросам безопасности уделяется много внимания. Более того, ICQ — один из немногих месседжеров в мире, у кого есть полноценная багбаунти-програма. А за время её существования мы заслужили высокие оценки и рейтинг на площадке HackerOne.
Спасибо, что делаете наши сервисы безопаснее! Ждём новых репортов!
Спасибо автору за то, что предварительно сообщил нам об обнаруженной проблеме. Благодаря этому мы смогли наградить его в рамках «Охоты за ошибками». Пишите нам в таких случаях.
Добрый день, я являюсь руководителем конкурса «Охота за ошибками».
В наших интересах, чтобы им пользовалось как можно больше исследователей безопасности. По нашей статистике количество случаев, когда в короткий промежуток времени о серьезной уязвимости сообщало больше одного пользователя, крайне мало.
Если у вас есть конкретные примеры, то изложите их, пожалуйста, здесь либо письмом.
Интересные идея и тула. Может помочь при ревью кода нового проекта. Это не замена SAST-решению, а скорее инструмент аудитору для быстрого понимания из чего (каких функциональных блоков) состоит проект.
Странно, что за все эти годы, таки и не сделали свободную (и не на Перле) альтернативу OTRS.
Очень жаль, что GitLab не полноценный FOSS и практически все фишки про безопасность только в максимальных лицензиях. При том, что сам он активно использует FOSS решения для безопасности.
+1 На вскидку:
Всё просто — это как теоретические основы в какой-нибудь области и практичные справочники.
«Проактивная защита: Топ-10 требований OWASP» как раз хорош кажущейся простотой и даже, возможно, банальностью. При этом в нём сделана хорошая попытка системно подать самые основы разработки безопасных веб-приложений.
Парадокс в том, что за каждым из перечисленных выше пунктов скрывается «большая часть айсбергов». В том смысле, что, например, рекомендовать экранировать все данные без учёта существования контекстов их вывода будет недостаточно. И вообще экранировать или всё-таки кодировать? 0_о В проверках всех данных на входе тоже можно наделать ошибок, а уж сколько всего скрывается за «простым» использованием TLS…
«Проактивная защита: Топ-10 требований OWASP», «Top-10 OWASP», «OWASP SAMM» и те же шпаргалки — всё это попытки с разных сторон (и подходов) помочь разрабатывать в результате безопасные приложения.
Здравствуйте!
Ещё раз спасибо классную находку, а также за то, что опубликовали краткий пересказ нашего общения в репорте. Для того, чтобы у читателей сложилась полная картина, ещё раз продублирую ссылку на полный дисклоз. В вашем посте поднято, как минимум, два важных вопроса.
Первый, конечно же, о самой уязвимости. Мы, признаюсь, по-началу были скептично настроены, из-за того, что вдруг заполучили такую "классическую дыру". По классификации OWASP она относится к Top 10-2017 A5-Broken Access Control и является очень критичной. Всем рекомендуется ознакомится с её описанием и тем, как в следующий раз так "больно не выстрелить себе в ногу". Благодаря вашему упорству нам удалось докопаться до сути проблемы, а, исправив, мы конечно добавили юнит-тестов безопасности.
Второй поднятый вами вопрос касается общения между вендором и исследователем. В своё время инициатива багбаунти программ кардинально изменила ситуацию этого общения к лучшему и дала возможность "белым шляпам" легально искать уязвимости в сервисах, делая их таким образом безопаснее, а взамен ещё и получать вполне весомую благодарность от вендора. Тем не менее, нам ещё есть над чем работать! Быть более открытыми и вежливыми друг-другу и стараться говорить на одном языке (см. Google Bughunter University).
В ICQ вопросам безопасности уделяется много внимания. Более того, ICQ — один из немногих месседжеров в мире, у кого есть полноценная багбаунти-програма. А за время её существования мы заслужили высокие оценки и рейтинг на площадке HackerOne.
Спасибо, что делаете наши сервисы безопаснее! Ждём новых репортов!
Заранее спасибо!
В наших интересах, чтобы им пользовалось как можно больше исследователей безопасности. По нашей статистике количество случаев, когда в короткий промежуток времени о серьезной уязвимости сообщало больше одного пользователя, крайне мало.
Если у вас есть конкретные примеры, то изложите их, пожалуйста, здесь либо письмом.