Знание черной шляпы для белых [закрытых] программистов шляпы
Нет простого способа сделать то, что ты просишь. Лучше всего иметь необязательную зависимость в A. В производственной среде зависимость будет отсутствовать и будет игнорироваться. В тестах вы предоставите компонент, содержащий вашу реализацию подготовки к тесту.
Да, вы добавляете немного дополнительной сложности ради тестов, которые не идеальны, но очень ограничены.
Прости страшные имена:
interface APreparer {
void prepareA();
}
@Component
public class A {
public A(final Optional<APreparer> preparer) {
preparer.ifPresent(APreparer::prepareA);
}
}
21 ответ
I'm coming in late on this, as I just heard about it on the podcast. However, I'll offer my opinion as someone who has worked on the security team of a software company.
We actually took developer education very seriously, and we'd give as many teams of developers as possible basic training in secure development. Thinking about security really does require a shift in thinking from normal development, so we'd try to get developers thinking in a how-to-break-things frame of mind. One prop we used was one of those home safes with the digital keypad. We'd let developers examine it inside and out to try to come up with a way of breaking in to it. (The solution was to put pressure on the handle while giving the safe a sharp bash on the top, which would cause the bolt to bounce on its spring in the solenoid.) While we wouldn't give them specific black-hat techniques, we'd talk about the implementation errors that cause those vulnerabilities -- especially things they might not have encountered before, like integer overflows or compilers optimising out function calls (like memset to clear passwords). We published a monthly security newsletter internally, which invited developers to spot security-related bugs in small code samples, which certainly showed how much they would miss.
We also tried to follow Microsoft's Security Development Lifecycle, which would involve getting developers to talk about the architecture of their products and figure out the assets and possible ways to attack those assets.
As for the security team, who were mostly former developers, understanding the black-hat techniques was very important to us. One of the things we were responsible for was receiving security alerts from third parties, and knowing how difficult it would be for a black hat to exploit some weakness was an important part of the triage and investigation processes. And yes, on occasion that has involved me stepping through a debugger to calculate memory offsets of vulnerable routines and patching binary executables.
The real problem, though, is that a lot of this was beyond developers' abilities. Any reasonably sized company is going to have many developers who are good enough at writing code, but just do not have the security mindset. So my answer to your question is this: expecting all developers to have black-hat knowledge would be an unwelcome and detrimental burden, but somebody in your company should have that knowledge, whether it be a security audit and response team, or just senior developers.
To the point where by learning their ways he starts to think in their direction. And then he must choose which side he wants "to belong to".
There is nothing malicious in technology itself ... knowledge is pure ... it's how you use it that determines how it shall be looked upon.
Вы должны понимать методы, которые используют «плохие парни», поэтому некоторое понимание обязательно.
Для Я думаю, что среднестатистическому разработчику достаточно ухватиться за основной принцип того, что они делают, чтобы избежать создания уязвимостей в своих проектах.
Для кого-то, кто работает в сфере безопасности (банковское дело или данные кредитных карт из интернет-магазин), требуется более глубокое понимание. Эти разработчики должны понять, как работает «плохой парень» и какие методы он использует.
Дизайн для зла . «Когда добро немо, зло всегда побеждает».
Короче говоря, если вы не думаете как преступник, это не значит, что преступники этого не сделают.
Я думаю, что часть «защитного кодирования» включает в себя знание вредоносных методов, но в то же время, вы не обязательно необходимо знать все приемы, чтобы эффективно противостоять им. Например, знание о атаках переполнения буфера не является причиной, чтобы попытаться защитить ваши буферы от переполнения. Вы защищаете их от переполнения, потому что, если они это сделают, это может нанести ущерб вашей программе, независимо от того, является ли это ошибкой или атакой.
Если вы напишите очень тщательно проверенный и хорошо спроектированный код, то злонамеренные атаки не смогут проникнуть потому что хорошая архитектура должна автоматически блокировать побочные эффекты и несанкционированный доступ.
Однако, последний абзац предполагает, что у нас есть идеальная работа, где нам дается невероятное количество времени, чтобы сделать наш код просто правильным , Поскольку такой работы не существует, знание злонамеренных методов является хорошим способом, потому что это означает, что, хотя ваш код не идеален, вы можете создавать «обходные пути» для тех подвигов, чтобы убедиться, что они не проходят. Но они не делают код лучше, и они не делают приложение лучше.
В конечном счете, знание о злонамеренных подвигах - это то, о чем стоит знать, но 95% из них будут охвачены простым соблюдением лучших практик.
Лично я не вижу технической разницы. Конечно, мотивы разные, но техническая игра та же. Это все равно, что спросить, о какой войне должны знать «вкусности». 1221] Ответ на все это, даже если они не практикуют это активно.
Это платит за то, чтобы быть «невинным, как голуби, и мудрым, как змеи», и изучать методы, которые люди с гнусными цели делают. Тем не менее, такие знания должны использоваться осторожно. «С великой силой приходит большая ответственность».
Я работаю охранником, а не разработчиком, и, основываясь на моем опыте, я могу просто сказать, что вы не можете учиться так хорошо, как черная шляпа или профессиональные белые шляпы, если только это не ваша вторая профессия , Это просто отнимает много времени.
Самое важное, когда видишь некоторых плохих парней или профессионалов в действии и понимаешь, каковы возможности и влияние небезопасного кода.
Итак, изучая некоторые трюки, но многие из них, можно почувствовать "ложного чувства безопасности", потому что он или она не может взломать. Хотя более опытный злоумышленник может взломать то же самое в течение нескольких минут. 1225 Сказав, что, как только вы запомните это, я думаю, что хорошо выучить некоторые атаки, весело и довольно познавательно, чтобы научиться ломать вещи.
Насколько, по вашему мнению, честный программист должен знать методы злонамеренных программистов?
Вам нужно знать больше , чем они.
В значительной степени. Тебе нужно думать как преступник, или ты недостаточно параноик.
Я собираюсь быть немного еретическим и выйти на конечность и сказать:
- Вы действительно нуждаетесь поговорить с Сисадмин / сетевые люди, которые защищают их машины. Эти люди имеют дело с концепцией взлома каждый день, и всегда находятся в поиске потенциальных способов использования против них. По большей части игнорируйте аспект «мотивации» мышления злоумышленников, поскольку дни «взлома для дурной славы» давно прошли. Вместо этого сосредоточьтесь на методологии . Компетентный администратор сможет легко продемонстрировать это.
Когда вы пишете программу, вы представляете, что (надеюсь) гладкий, гладкий интерфейс для $ {what-else-accept-your-Programs-I / O} , В этом случае это может быть конечный пользователь или другой процесс на другом компьютере, но это не имеет значения. ВСЕГДА предполагают, что «клиент» вашего приложения потенциально враждебен, независимо от того, машина это или человек.
Не делайте не веришь мне? Попробуйте написать небольшое приложение, которое принимает заказы на продажу от продавцов, а затем разработайте правило компании, которое необходимо применять в этом приложении, но продавцы постоянно пытаются обойти это, чтобы заработать больше денег. Только это небольшое упражнение покажет, как мотивированный злоумышленник - в данном случае предполагаемый конечный пользователь - будет активно искать способы либо использовать недостатки в логике, либо обыгрывать систему другими способами. И это доверенные конечные пользователи!
Многопользовательские онлайн-игры постоянно ведут войну с мошенниками, поскольку серверное программное обеспечение обычно доверяет клиенту; и во всех случаях клиент может и будет взломан, в результате чего игроки разыграют систему. Подумайте об этом - у нас есть люди, которые просто веселятся, и они будут использовать крайние меры, чтобы взять верх над деятельностью, не связанной с зарабатыванием денег.
Просто представьте себе мотивацию профессионального бот-скотовода, который зарабатывает себе на жизнь таким образом ... пишет вредоносные программы, чтобы они могут использовать чужие машины в качестве источников дохода, продавая свои ботнеты самой высокой цене за массовые спам-рассылки ... да, это действительно происходит .
Независимо от мотивации, точка остается, ваша программа может и в какой-то момент подвергнется атаке. Недостаточно защитить от переполнения буфера , разрушение стека , выполнение стека (код в виде данных загружается в стек, затем выполняется возврат для выгрузки стека, что приводит к выполнение кода), выполнение данных , межсайтовый скриптинг , повышение привилегий , условия гонки или другие «программные» атаки, хотя это и помогает. В дополнение к вашей «стандартной» программной защите, вам также нужно думать о доверии, проверке, идентификации и учетных данных - другими словами, иметь дело с тем, что обеспечивает ввод вашей программы и что потребляет вывод вашей программы. Например, как защититься от DNS-отравления с программной точки зрения? И иногда вы не можете избежать вещей в коде - пример того, как ваши конечные пользователи не передают свои пароли коллегам.
Включите эти концепции в методологию для обеспечения безопасности, а не "технология". Безопасность - это процесс, а не продукт . Когда вы начнете думать о том, что находится «на другой стороне» вашей программы, и о методах , которые вы можете использовать для смягчения этих проблем, станет намного яснее, что может пойти правильно, а что можно пойти ужасно неправильно.
В конце концов, «черные шляпы» ничего не знают о криминальном знании, это только то, как эти знания применяются , Глубокое понимание любой технологии является ценным для программиста, это то, как мы получаем максимальную отдачу от системы. В наши дни можно обойтись без знания глубины, поскольку у нас появляется все больше и больше фреймворков, библиотек и компонентов, которые были написаны с использованием таких знаний, чтобы избавить вас от необходимости знать все, но время от времени копать полезно.
2 стороны одной медали. Кроме намерения - в чем вопрос? Одинаковые навыки, разная реализация.
мы, белые шляпы и серые шляпы, должны хорошо разбираться в миллионе вещей, которые эти черные шляпы и заносы должны преуспеть только с одной целью
Я собираюсь занять спорную позицию и сказать, что есть кое-какие знания в черной шляпе, которые вам не нужны. хороший хакер в белой шляпе Врачу не нужно знать, как генетически сконструировать вирус, чтобы эффективно лечить болезнь.
Один из приемов, которые Белые шляпы должны освоить, - это как тестировать / смягчать / мыслить с точки зрения социальной инженерии, потому что самая большая угроза безопасности - это люди.
Белые шляпы хороши в манипулируя битами, но люди - это те, которыми манипулируют чёрные шляпы гораздо чаще.
Одним из часто пропускаемых умений является социальная инженерия.
Многие люди просто не узнают, когда их обманывают. В предыдущей компании вице-президент проводил тестирование, имея трех (временных) временных сотрудников в конференц-зале, программистов и системных администраторов, которые работают над сценарием, чтобы попытаться заставить кого-то предоставить доступ или раскрыть пароли. Каждый из временных сотрудников получил доступ к чему-либо в первый час разговоров.
Бьюсь об заклад, если бы подобный тест проводился в любой средней и большой компании, они получили бы те же результаты.
Определенно изучите темную сторону. Даже если вы не изучите реальные методы, по крайней мере, приложите усилия, чтобы узнать, что возможно.
Хорошими ресурсами для изучения уловок торговли являются Реверс: Секреты обратного проектирования и Хакерство: искусство эксплуатации . Они написаны для обеих сторон - их можно использовать, чтобы УЧИТЬ, как взломать, но они также дают способы предотвратить подобные атаки.
Одно слово предостережения: Штат Орегон против Рэндала Шварца .
Будучи небольшой частью расследования двух отдельных инцидентов на нашем сайте, я бы сказал, шансы узнать о подвиге до того, как оно будет использовано против вас, ничтожно малы. Возможно, если вы посвятите свою карьеру тому, чтобы быть белой шляпой, вы останетесь на вершине всех потенциальных дыр в большинстве популярных аппаратных / программных стеков. Но для обычного программиста вы, скорее всего, находитесь в режиме реакции.
Вы обязаны знать, как может быть взломано ваше собственное программное обеспечение, и нести ответственность за то, чтобы быть в курсе последних событий со сторонним программным обеспечением. Было бы хорошо иметь план действий в чрезвычайных ситуациях, чтобы справиться с атакой, особенно если вы - крупная или высокоценная цель. В некоторых местах захочется немедленно закрыть дыру, но наш сайт имеет тенденцию оставлять открытые дыры, чтобы помочь правоохранительным органам в поимке преступников. Команда ИТ-безопасности иногда внутренне объявляет, что будет проводить сканирование портов, чтобы SA не волновался по этому поводу.
Basically almost all security exploits used by hackers are bugs in the code introduced by poor programming style or disciplines. If you write code to protect against bad data and invalid call operations you'll block the majority of security vulnerabilities in your code.
If you're interested to protect your code from hacking/abuse/etc. you'll spend way too much time on it. Just buy a package to protect the basics and just move on.
Когда я слышу слово «черная шляпа», я думаю о ком-то, кто использует знания о компьютерах, чтобы взламывать банки и делать другие плохие вещи. Белая шляпа знает все , что знает черная шляпа, но ничего плохого с этим не делает.
Следовательно, у вас нет заботы или знания ] что за "черная шляпа", чтобы быть в безопасности ...
Знание того, как думает черная шляпа , когда вы уже эквивалентны белой шляпе, которая не помогает приседать. Это как знать: «Джон хочет ворваться в мой дом и украсть мою музыку с iPod». Если вы действительно заботились о музыке на iPod, вам в любом случае следовало бы защитить ее.