1. Куча / Говнокод #23500

    +1

    1. 01
    2. 02
    3. 03
    4. 04
    5. 05
    6. 06
    7. 07
    8. 08
    9. 09
    10. 10
    11. 11
    12. 12
    13. 13
    14. 14
    15. 15
    16. 16
    17. 17
    18. 18
    19. 19
    20. 20
    21. 21
    22. 22
    23. 23
    24. 24
    Шел 21-й год веб программирования. 
    
    ---Программисты не умели в prepared statements и CSRF 
    — Какие ошибки в аспекте безопасности чаще всего допускают разработчики приложений .NET Framework?
    Михаил: По моему опыту проведения security review веб-проектов – 
    это всевозможные инъекции «в широком смысле слова»: XSS, SQLi, XXE, Path Traversal и проблемы конфигурации приложений
    Сервер WinCC Web Navigator написан на платформе .NET, и исследователи нашли целый ворох уязвимостей в нем: 
    XPath Injection, Path Traversal, больше 20 XSS, CSRF, SQLi и другие. 
    
    ----------------Программисты не умели в капчу
    .., и в результате атакующему удалось подобрать пароли к более чем десятку учетных записей, прежде чем атака была остановлена
    
    --------------В соль, похоже что, тоже не умели (программисты RSDN!!!)
    После этого мы взяли базу хэшей паролей пользователей и осуществили оффлайн-атаку подбора паролей по словарю из ~250K элементов. 
    В результате на 83165 зарегистрированных на тот момент пользователей пришлись 11017, чьи пароли удалось подобрать в разумное время.
    
    ---(неуверенно) и в assertы тоже не умеют?...
    "Если же говорить о C#, то, с точки зрения безопасности, в нем очень не хватает встроенных средств контрактного программирования.
     Хотя бы на том уровне, на котором это реализовано в языке Nemerle,
     где для любого метода или класса могут быть определены функции, подтверждающие выполнение пред- и постусловий для методов или 
    обеспечивающие контроль инвариантов в случае классов"
    
    
    https://habrahabr.ru/company/jugru/blog/341792/

    давайте сраться

    Запостил: SemaReal, 08 Ноября 2017

    Комментарии (37) RSS

    • mea culpa
      соль не причем: Они спиздили соль и хеши и хешировали слова из словаря с этой солью.
      Остальное всё равно пездец
      Ответить
    • > В соль, похоже что, тоже не умели (программисты RSDN!!!)
      > После этого мы взяли базу хэшей паролей пользователей и осуществили оффлайн-атаку подбора паролей по словарю из ~250K элементов.
      > В результате на 83165 зарегистрированных на тот момент пользователей пришлись 11017, чьи пароли удалось подобрать в разумное время.
      Хочу с этим поспорить.
      Тут, как мне кажется, пользователи сами виноваты.
      Даже если посолить и сделать хэш-функцию Борманда (http://govnokod.ru/23401#comment391188), которая считается не менее, чем за минуту на современном железе, пользователь всё равно поставит пароль 12345, и его сломают ровно за одну итерацию - за минуту. Тут разве что приватную соль Борманда (http://govnokod.ru/23401#comment391320) использовать на суперсекретном сервере, который никогда не будет взломан. Хотя, тогда можно будет просто не сливать хэши, а пойти и на сайт залогиниться :)
      Ответить
      • Да, я уже понял что обосрамшись: http://govnokod.ru/23500#comment393614

        но остальное в силе
        Ответить
        • Тьфу... Неграмотный я, не проникся латынью. Полез сраться, раз был призыв.
          Ответить
    • Меня беспокоит, что в программировании идут не по пути открытия доступа к возможностям, а по пути поиска уязвимостей и затыкания дыр. И выходит, что любой код потенциально содержит уязвимости, которые ещё не были обнаружены.

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

      Оказывается, что вся криптография - это security through obscurity. Все наши решения надёжны только потому, что хакеры пока не знают, как их взломать. Если информация где-то есть, значит кто-то сможет её оттуда достать. И это печалит (впрочем, только до того момента, когда я забуду пароль от какого-то важного файла, и добрый хакер поможет мне не потерять его).
      Ответить
      • > вся криптография - это security through obscurity
        Ну не совсем. В нормальной криптографии все алгоритмы и протоколы считаются известными атакующему и проектируются с учётом этого. Их тысячи людей ревьювят, пытаются взломать и т.п.

        А through obscurity это когда твой алгоритм держится на соплях и сдаётся через пару дней после того, как о нём кто-то узнает.
        Ответить
        • > В нормальной криптографии все алгоритмы и протоколы считаются известными атакующему
          Скажите, а уязвимости и недочёты алгоритма - это его неотъемлемая часть или какая-то магия, которая возникает, когда кто-то находит дыру?
          Чем на практике отличается бэкдор для спецслужб или скрытый баг от необнаруженной уязвимости, кроме того, что в первом случае автор скрывает нарочно и может сам воспользоваться, а во втором - ненарочно?
          P.S. Вопросы философские, но ОП хотел срача :)
          Ответить
          • Недоглядели или ещё не знали о какой-то новой концепции. Но с публичными алгоритмами, которые выжили несколько лет, такая фигня случается намного реже, чем с приватными поделками. Просто шума много после каждой дыры. И реализации добавляют свои косяки.
            Ответить
      • > Все наши решения надёжны только потому, что хакеры пока не знают, как их взломать.

        Некоторые решения надёжны потому, что любой знает как их взломать, но время, необходимое для взлома на практике больше, чем актуальность взламываемых данных.
        Ответить
        • > Некоторые решения надёжны потому, что любой знает как их взломать, но время, необходимое для взлома на практике больше, чем актуальность взламываемых данных.
          Они надёжны потому, что хакеры пока не знают, как их взломать быстрее, чем предусмотрено создателем криптосистемы.

          Постоянно идёт такой диалог:
          Криптограф: Привет, у меня новое крипторешение. Ключ 256 бит - ломать будете столько, сколько живёт вселенная :)
          Аналитик: У тебя там не секретные биты, а число 42 выходит, и я это математически докажу. В общем, 128 бит.
          Криптограф: ОК, ломайте мои 128 бит 100 лет на всех ваших суперкомпах.
          Аналитик: Лол, да тут можно по длине сообщения и гигабайту данных восстановить половину ключа. 64 бита.
          Криптограф: Хорошо, давайте усилим алгоритм генерации, будет вам 70 бит на первое время.
          Аналитик: Оказалось, что вон те твои формулы друг друга компенсируют и дают только 65536 вореаций ключей. Выносите.
          Ответить
          • Именно поэтому криптоалгоритмы и существуют не в вакууме, а в коммьюнити, и время на научные исследования (на то, чтобы вдруг осознать, что там всего 65530 вореций) входит в устойчивость алгоритма. Создатель алгоритма на момент его создания не знает, что его 256 бит сводятся к 16-ти и не пытается это скрыть, а как раз наоборот. Обычно на момент создания алгоритма ещё не существует научных методов, которые позволяют его скомпрометировать.

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

            И, если я правильно тебя понял, ты наезжаешь на всю науку и человеческую цивилизацию в целом, мол, не охуели ли вы ошибаться и так медленно развивать технологии? Что в диалоге, который ты привёл, плохого?
            Ответить
            • > что алгоритм постоянно находится под надзором тысяч глаз, а взломать его -- очень привлекательно
              Алгоритм под надзором, но баг в нём никто не видит. И это почти не отличается от случая, когда про баг знает тайное общество.

              > И, если я правильно тебя понял, ты наезжаешь на всю науку и человеческую цивилизацию в целом, мол, не охуели ли вы ошибаться и так медленно развивать технологии? Что в диалоге, который ты привёл, плохого?
              Можно распространить претензии на всю человеческую деятельность, да. Правда, я не думал об этом, когда писал.
              В криптографии просто это особо остро чувствуется. В других областях НТП обычно приносит улучшения и исправления, при которых старая версия ещё работает. Например, обычный скучный стул заменяется новым стулом-трансформером, который едет сами и принимает форму тела. Обычный стул при этом не разваливается под сидящим, и продолжает служить ему ровно столько, сколько нужно. При появлении нового лекарства люди не начинают ВНЕЗАПНО умирать от старого. Да, может оказаться, что старое было ядом, но это знание не убьёт больше людей. А в криптографии любое новшество может обернуться наплывом хакеров и ботов, которые будут бодро шелестеть обёрткой в прошлом надёжной криптосистемы и распоряжаться твоими данными как хотят. Криптосистема не работает надёжно долгие годы как старый скучный стул, и заставить её так работать почти невозможно.
              Ответить
              • Твой пример про стул не верен. Стул, заметь, и не с такой скоростью развивается, и не такую ответственную роль играет. А в примере про лекарство ты как раз сам себе противоречишь. В качестве лечения раньше сверлили дырку в башке, чтобы кровь стекла. Появились новые методы, и где кровопускание? Можно ещё подорожника приложить.

                Сравни лучше с оружием, что-то я не видел, чтобы сейчас кто-то против гранатомёта с копьём вышел. Как же так, появился пистолетик и вдруг все сабли и шпаги пиздой накрылись?

                Вот ты, конечно, крэйзи, братан.
                Ответить
                • > Твой пример про стул не верен. Стул, заметь, и не с такой скоростью развивается, и не такую ответственную роль играет.
                  Давайте уберём все стулья и офисные кресла (стулья на колёсиках), а потом посмотрим. Как вообще можно недооценивать роль стула? Это фундаментальная вещь, которая используется во всех сферах жизни; задаёт тон работы множества людей; принимает активное участие в праздниках и мелькает на ТВ.

                  Хорошо, заменим стул телефоном. Он создан совсем недавно даже по сравнению с криптографией, развивается быстро, распространён примерно как стул, а т.к. содержит электронную питушню, кажется более важным крэйзи посетителям ГК.
                  Дисковые телефоны не стали плохими или уязвимыми, когда появились кнопочные (хотя, при переходе на тональную питушню они стали болванками, но это нейтрально, это не вред). Стационарные телефоны не стали плохими и уязвимыми, когда появились мобильные. Мобильные телефоны не становятся хуже при выходе новых аналогов. (Хотя, занятно наблюдать за теми, кто смеётся над очередями за ифонами, но в то же время покупает новый телефон на андроиде раз в 2-3 года, когда твой телефон отлично работает уже 5-10 лет).

                  >> В других областях НТП обычно приносит улучшения и исправления, при которых старая версия ещё работает.
                  >> При появлении нового лекарства люди не начинают ВНЕЗАПНО умирать от старого. Да, может оказаться, что старое было ядом, но это знание не убьёт больше людей.
                  > А в примере про лекарство ты как раз сам себе противоречишь.
                  Где противоречие? Сверление дырок в голове стало более опасным, когда наука продвинулась? Тем, кому сверлили дырку, стало хуже из-за открытия новых методов (исключая психологический фактор)? Скорее всего нет, сверление дырок в голове сейчас работает так же (или даже лучше за счёт новой анестезии и большей стерильности инструментов), как и до открытия новых методов.

                  Оружие эквивалентно криптографии, это да. А ещё замки и какие-нибудь антивор-, антимат- и античит-системы.
                  Ответить
                  • > Стационарные телефоны не стали плохими и уязвимыми, когда появились мобильные.

                    Стали плохими. Их нельзя брать с собой. Дисковые телефоны -- говно ебаное. Благодаря тому, что появились мобильные, стационарные автоматически стали говном. Они хуже относительно мобильных, они плохие. Так же как и криптографический алгоритм сам по себе не хорош и не плох, а становится плохим по мере появления нового алгоритма или средства взлома, это гонка относительная. Иначе можно сказать, что MD5 тоже не стал плохим, он же такой красивый, и работает.

                    Так вот, что самое интересное, старые телефоны стали ещё и уязвимыми по сравнению с мобильными. Сложность перехвата мобильных разговоров, протоколы и криптография, существующая там, и рядом не стоят с возможностью спуститься в подвал жилого дома, открыть отвёрткой ящик, кинуть два провода от трубки на любой номер и слушать твои разговоры. Там вообще нет никакой защиты. Старые телефоны говно по сравнению с новыми. Пользоваться ими небезопасно с точки зрения секьюрити, неудобно и незачем.
                    Ответить
                    • Стационарные телефоны не стали плохими. Их никогда нельзя было брать с собой. Просто их вытеснили конкуренты, потому что конкурентов можно брать с собой.

                      Есть места, в которых стационарные телефоны до сих пор используются. Например, служебные телефоны.
                      Ответить
                      • Функция, для которой мы знаем алгоритм взлома не стала плохой. Её ВСЕГДА можно было так взломать. Просто её вытеснили конкуренты, для которых мы пока не знаем алгоритма взлома.

                        Есть места, в которых взломанные функции до сих пор используются. Например, быстрые хеши с низкой вероятностью коллизии, который нужен, чтобы просто различать строки, не защищать их.
                        Ответить
                        • Аналогия неправильная. Её всегда можно было взломать или она всегда была взломанной?
                          Ответить
                        • > Функция, для которой мы знаем алгоритм взлома не стала плохой. Её ВСЕГДА можно было так взломать.
                          Кстати, что-то такое я и писал выше, об этом и сожалел.

                          Но на практике до того, как стала известна "новая математика", существующие алгоритмы взломать нельзя, а после того, как стала известно - можно.
                          Это всё равно, что кто-то изобрёл бронированные окна и одновременно раздал всем мальчишкам рогатки. Старые окна работают, но внезапно стали доставлять кучу проблем.

                          Если кто-то просто создал новый алгоритм, не взломав старый (добавил больше бит, ускорил вычисления и т.п.), то старый продолжает работать, и с него перелезают чисто ради новых фич (как происходит с телефонами). Это как изобрести бронированные окна и не давать мальчишкам рогатки.
                          Ответить
                      • Трубку стационарного телефона удобно было держать без рук, чего не скажешь о мобилах, которые всё тоньше и тоньше...
                        Ответить
                    • > спуститься в подвал жилого дома, открыть отвёрткой ящик, кинуть два провода от трубки на любой номер и слушать твои разговоры

                      На цифровых АТС на каждом этаже стоит коробочка, которая оцифровывает и шифрует голосовой канал. В подвале тебе доступен только зашифрованный трафик.
                      Ответить
                      • Was?!

                        Цифра идет только между АТС и внутри АТС (ATM и иже с ним) а последняя миля аналоговая. Во всяк случае в старых домах. Иначе не было бы ебли с дайлапом в моем децтве.

                        Да и ADSL использует полосу шире, чем нужна для голоса, ее никто бы цифровал просто так бы
                        Ответить
                    • Соглашусь со сказазанным inkanus-gray: Их никогда нельзя было брать с собой.

                      Если не рассматривать аспект безопасности (т.к. 1. все и так согласны, что ради неё приходится отказываться от старых решений, и это не обсуждается и 2. телефон как таковой может быть использован для несекретных переговоров), старые телефоны не стали хуже.
                      Вот если бы кто-то опубликовал лёгкий способ посветить мощным лазером в микрофон, чтобы выжечь ухо собеседнику, тогда старые телефоны стали бы внезапно хуже.
                      Ответить
                      • > Вот если бы кто-то опубликовал лёгкий способ посветить мощным лазером в микрофон, чтобы выжечь ухо собеседнику
                        https://youtu.be/bS5P_LAqiVg?t=7m49s
                        Ответить
    • # не хватает встроенных средств контрактного программирования

      На самом деле даже if (arg == null) throw new NullReferenceException(nameof(arg)); тоже контракт.
      Или например класс Contract.

      А ещё даже анализатор Microsoft для C# выдаёт предупреждение на непроверенный аргумент в методе.
      Ответить
      • вот да. Вот если бы это проверялось статически то было бы клево. Только представь себе:

        [NotNull] void DoAll([Regexp{"[a-z]{2}"}] string Code)
        Ответить
        • > Вот если бы это проверялось статически то было бы клево.
          Да. Хорошо бы вообще проверять всё проверяемое статически, а на непроверяемое выдавать ошибку или просить уточнить.
          Чтобы не было тормозных проверок всего и вся по 100500 раз, чтобы не было забытых проверок, чтобы не было дебаг-онли проверок в assert, подразумевающих тщательное тестирование каждой возможности в рантайме.
          Ответить
        • > Только представь себе

          Это тривиально сделать без всяких контрактов, просто правильно используя систему типов и умные конструкторы.
          class Code { private char[2] code_;
            public static ErrorOr<Code> OfString(string s);
            public static ErrorOr<Code> OfChars(char a, char b);
          }
          
          void DoAll(Code code);
          Т.е. под каждый констрейнт делаешь по типу, инстансы которого нельзя сконструировать из кривых данных. Используешь эти типы в сигнатурах.

          > [NotNull] void
          щито
          Ответить
          • >>class Code { private char[2] code_;
            Это очень удобно. А теперь пожалуйста тоже самое для числа от -42 до 38.

            >>щито
            да ничего, глупость я написал. Ну поменяй void на String какой-нить
            Ответить
            • > А теперь пожалуйста тоже самое для числа от -42 до 38.

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

              Подобные типы не так хорошо работают, когда нужна зависимость между параметрами, например, если размер входа связан с размером выхода, или на входе массив и индекс, который должен быть валидным. Вот в таких случаях дествительно могут полезны констрейнты. Зависимые типы предлагать не буду, у вас от них голова лопнет.
              Ответить
              • >> Уж лучше в одном месте описать тип и использовать всюду, чем копипастить подобные констрэйнты.
                Ну тогда нужно чтобы ЯП делал хорошее приведение типа, или хотя-бы позволял перегружать этот процесс.

                >>апример, если размер входа связан с размером выхода
                Можно эмулировать перегрузкой.

                >>Зависимые типы предлагать не буду
                Это из серии "список целых где [N+1] > [N]"?

                наверняка какие-то фунциональные ЯПы это умеют

                >>у вас от них голова лопнет
                у нас -- это у PHPшников всмысле?
                Ответить
    • да блять русские заебали ленится и гавно писать!!! на заводвсех
      Ответить

    Добавить комментарий