«В своей маркетинговой политике WhatsApp использует слова «сквозное шифрование» как магическое заклинание, которое само по себе должно автоматически обеспечивать безопасность всех коммуникаций. Однако эта технология не может сама по себе гарантировать вам абсолютную конфиденциальность», — продолжает Дуров.
Пока в Телеграме нет этого самого сквозного шифрования для всех чатов по умолчанию, о чём вообще можно говорить?
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.
Спасибо, что делаете наши сервисы безопаснее! Ждём новых репортов!
Заранее спасибо!
В наших интересах, чтобы им пользовалось как можно больше исследователей безопасности. По нашей статистике количество случаев, когда в короткий промежуток времени о серьезной уязвимости сообщало больше одного пользователя, крайне мало.
Если у вас есть конкретные примеры, то изложите их, пожалуйста, здесь либо письмом.