Как может я сканирование/пух мой код для уязвимостей?
Мотивация
, В первую очередь: Читайте Peopleware
Затем. Почему Вы думаете, что наказание будет эффективным способом управлять людьми, который, как предполагается, является творческим? Я думаю, что необходимо заново продумать целый подход к управлению по сравнению с командой.
, Поскольку я вижу его менеджеры сначала, и самый важный, роль состоит в том, чтобы удостовериться, что разработчики могут быть творческими и продуктивными. Не то, чтобы они продуктивны. Существует большая разница в тех небольших словах. Чтобы быть творческими, Вам нужна безопасная среда. Будучи постоянно под давлением и с крайних сроков и с угроз наказания Вы создаете полную противоположность сейфа.
кроме того, как менеджер, Вам нужна достоверная информация, на которой можно основывать решения. Это также требует безопасной среды. Если существует риск для наказания за то, что были честны, и откровенными Вы, как гарантируют, доберетесь, находится и отсутствие информации. Очень опасная основа для принятия решений от.
Оценки
Как другой, как указано, оценки являются оценками. В нашей команде мы не делаем никаких отдельных оценок вообще, мы делаем оценки как команда. (Я немного отказываюсь назвать то, что мы делаем Толпу, но большая часть из нее пытается эмулировать, если ничто меньше) я думаю, что это - действительно отличный способ сделать оценки: Каждому члену команды дают деку карт, состоящих из чисел 0,1/2,1,3,5,8,13,20,40,60,100 и при оценке задачи, каждый разработчик выбирает карту (карты скрыты, пока все не выбрали карту, чтобы не влиять на оценки), и среднее число выбранных плат взято в качестве оценки.
Уведомление, как числа прогрессивно становятся менее точными. Это дизайном, потому что большие оценки при необходимости менее точны.
Для нашей команды мы решили использовать единицу "идеальные дни человека" для оценок. Еще любой из нас может помнить, что идеальный день еще не произошел, но это - хорошая основа, когда Вы знаете, как перевести дни каландра в "идеальные дни человека".
, Поскольку Толпа предписывает, разработка сделана в спринтах двух недель, после которых новая версия развертывается в продуктивной среде. После каждого спринта мы берем сумму оценок выполненных задач и делим это к запланированным дням человека для спринта. Этим фактором является тогда основание оценки, сколько "идеальные дни человека" команда могут потратить в двухнедельный период.
для Фактических объектов работы, сделанных отдельным разработчиком, не нужна оценка. Первое приближение всегда 1/2 - 1 день для завершения. Если эта оценка оказывается ложью, Вы просто захватываете такого же разработчика и делаете это вместе, чтобы сделать ее. Или Вы ломаете объект работы в меньших задачах, таким образом, он может быть распределен лучше.
5 ответов
To strictly answer your question the way you should test is by using a tool. There are 2 main types of tools you can use, a security scanner which actively probes a running website or a static analysis tool which runs on the source code you use to build your webapp.
The short answer is you want a security scanning tool like wapiti or burp. Tools like these dynamically construct and execute security tests uniquely for your site. You could manually attempt to exploit your own site but that would take lots of time and not provide any value. It would be useless for you to go through a list of known xss or sql injection issues because each issue is unique to the site it applies to. Furthermore these tools can attack your site better then you can giving you a more rigorous security stress test.
There are 2 main tools you can use, static analysis tools and dynamic analysis tools. Static analysis tools read in your source code, figure out the way the data flows through the app and look for security issues. At their root most security issues are allowing a user to control some data that flows into an inappropriate part of an application so even though the app isn't running and you rub up against the halting problem, static analysis method of "guessing" and trying out each code path can yield good results. Static analysis tools are language dependent and most are expensive. Some free ones are fxcop (C#), PMD and findbugs (java), see http://en.wikipedia.org/wiki/List_of_tools_for_static_code_analysis
Dynamic analysis tools (more commonly just called "security scanner") require you setup your webapp so it can run tests against it, this sounds like more what you want. My favorite tool here is burp, some free ones include wapiti which is good as well. These tools will look at how your app handles data, look for inputs and fill them with malicious data in an attempt to trigger vulnerabilities. An example test would be for testing reflected cross-site scripting, the scanner would look at a page and insert javascript into every querystring value, cookie value, form value etc and then render the page to see if the malicious javascript was echod back to the page.
You likely don't need or want a fuzzer. Fuzzing tools mostly help you when there is a lot of parsing code so a fuzzer is not the best fit for a webapp whereas it would be a good fit for a protocol you are making. There is limited fuzzing capabilities in the security scanner tools listed above and you probably don't need more then this. Fuzzers also take time to build. Fuzzers often find more stuff in c/c++ code because there are less libraries built in already doing the right thing, in the webapp case there is less "room for fuzzers to play" so to speak.
Прежде чем вы сойдете с ума по автоматизации (которая, вероятно, даст результаты, которые вы, вероятно, не поймете), я бы посоветовал вам вместо этого прочитать о написании безопасного кода и научиться определять, что вы делаете неправильно. Вот несколько руководств, которые помогут вам начать:
http://php.net/manual/en/security.php
В противном случае я бы предложил передать ваш код на аутсорсинг в охранную фирму, если вы можете себе это позволить.
Удачи!
При условии, что вы знаете C, вы можете работать со спайком. Всегда хорошо выполнить ручную проверку на переполнение во всем, что предположительно может быть затронуто конечным пользователем. Обычно% x% x % x тесты для атак на строку формата, и просто для тщательного статического анализа.
PeachFuzz и SPIKE оба хорошо задокументированы.
В противном случае написать свой собственный тривиально.
Существуют службы , которые будут выполнять автоматическое сканирование на наличие уязвимостей. Они не уловят всего, но помогут выявить проблемы. Лучше всего использовать одну из этих служб и УЗНАТЬ НЕКОТОРЫЕ МЕТОДЫ БЕЗОПАСНОСТИ.
Начните изучать внедрение SQL и межсайтовый скриптинг . это самые большие уязвимости, которые легче всего исправить.
Защитное программирование - это навык, которым, ИМХО, должен овладеть каждый программист.
Нет никакой замены самостоятельному пониманию этих проблем.
Знание того, что такое фаззинг и как вы, возможно, захотите подойти, не обязательно приводит к навыкам, необходимым для тщательного тестирования и оценки вашего программного обеспечения на наличие уязвимостей и недостатков. Вам нужно использовать автоматическое тестирование, но настроенным образом, когда вы изменяете тестирование, выполняемое инструментом, по мере того, как вы обнаруживаете новые пути ввода, взаимодействия и т. Д.
По сути, я хочу сказать, что вам нужно знать, что вы делаете, если вы хотите, чтобы это принесло реальную добавленную стоимость. Вы не можете просто выбрать инструмент, запустить его и рассчитывать на хорошие результаты. Вам нужен кто-то, кто проводит такое тестирование, чтобы работать с вами или для вас. Инструменты полезны, но могут дать полезные результаты только тогда, когда их использует специалист в данной области.