Tag Info

Hot answers tagged

17

Microsoft's guidelines for Security Development Life-cycle (SDL) for Agile recommends security practices during design, implementation, and release of the project. Regardless of the development methodology in use, no line of code should make it into production until it has undergone a security review. If financial constraints are preventing this level of ...


16

Unfortunately there are no automated scanners to detect all the types of vulnerabilities in modern web applications (I often hear less than 50%). Relying only on automated solutions is fraught with shortcomings. Automated scanners can expose the easy stuff, but you need human intelligence to explore and reveal additional vulnerabilities. With that said, ...


15

The short answer is: integrate security into your software development lifecycle. It should be integrated into every stage: design, implementation, and testing. There are many resources on how to build security into your software development lifecycle. See, e.g., Cigital's SDLC (the 7 touch points)], Microsoft's SDLC, OpenSAMM's SDLC, BSIMM, CERT's Build ...


12

I'd like to point you to open source tools that we use in pen-testing web applications: Arachni, already mentioned in a previous answer. w3af, one of the most famous free open source scanners. This one is written in python and have a consistent UI (GUI and CLI). The project is sponsored by Rapid7, owners of Metasploit and NeXpose Skipfish, a fire and ...


10

Some good answers here, but I think some points were missing: Automatic tools finish a lot faster than manual testing, by orders of magnitude. Automatic tools cover the breadth, but you need manual testing for depth. (Breadth both in range of attacks/tests, and in probing all interfaces / lines of code). Autotools are great for the common low hanging ...


10

There's also the Pentest Standard


9

It depends on what your requirements are. A sufficiently complex and well-designed system could be used to identify the most simple backdoors or trapdoors in most programming languages. However, if a language is Turing complete, any single expression or function can be expressed in an infinite number of ways, which makes such analysis equal to the halting ...


7

Check out the Web Application Security Scanner List from The Web Application Security Consortium (WASC). Note, I'm one of the authors of Watcher which is a free and open source passive vulnerability scanner on this list. This list also includes the Software as a Service scanning solutions.


7

Good answer from Chris Frazier, although I wouldn't personally recommend the CEH. Perhaps I took the test way too long ago, but didn't feel it covers anything close to what a penetration tester or a security-aware developer actually needs. Perhaps I'm going to give you a slightly unorthodox answer, but it sounds to me like you're already doing quite an ...


7

No. You should not use tools like Zeus or Havij, or other black-hat tools, to assess the security of your site. Zeus isn't designed for vulnerability assessment; they're designed for placing a backdoor once you're in. In general, my experience is that the black-hats don't have better vulnerability assessment tools than white-hat penetration testing and ...


7

Perhaps it helps to talk about a real world analog. Say your customer has a brick and mortar store. How do you verify it is secure? First you must understand the threat model. Is it a lemonade stand, a convenience store, or a jewelry store? They all require very different levels of security. Then you must implement the controls required for that type of ...


6

I think your a little confused over some of the tools, for example Zeus is a trojan and not used for general website pen testing. But regardless, there is no magic toolkit you can use for web site assessment. Because of the dynamic nature of web development it really does take a human presence to analyze and find most vulnerabilities. Relying solely on a ...


6

I don't have numbers for you, or specific guidelines, but I think an important issue to point out, but was not sufficiently emphasized in those links, is Code Coverage. It makes little sense to run a huge number of fuzz iterations, if they are all similar - from a code path point of view. That is, "dumb fuzzing" may generate many different inputs ...


6

I'd reiterate AviD's reply - Cross Site Scripting is generally better solved as a context sensitive output encoding problem, rather than an input validation problem. If you're trying to solve it as an input validation problem, you're going to be encouraging a black list input validation approach in many cases, or if you're using a white list approach you may ...


6

NIST 800-53A and NIST 800-115 That's not strictly a test plan, but it is a catalog of the elements of a test plan. If you're working with a government system, that is a list of test standards for the security controls. If you're working on a commercial system, it is a catalog of resources. Another resource for test plans is SANS Critical 20 Security ...


6

How's My SSL? (new) ssllabs-clienttest; very basic yet. SSL Cipher Suite Details / https://cc.dcsec.uni-hannover.de/


5

Going a bit off-topic from IT Security...a 'certification' is a very dangerous thing from a liability perspective.I would advise a good read of the small print on any 'certification' service - if they are offering something which will stand up when needed (ie if the website gets hacked you can claim or pass the blame) I would be very astonished. What is ...


5

There is a good resource on MSDN. Did you had a chance to read about this topic in MSDN Magazine? Well, here you are the links that may help to define what you look: Penetration Testing Vulnerability Assessment and Penetration Testing Plan Templates


5

If your security model is based around the concept of a point-in-time external audit of your entire codebase, then you're doing security wrong. ...And you're probably using the audit wrong too. But we'll get to that. Beyond question, all code needs to be audited for security. In many cases, this is actually a legal requirement: no code ships without an ...


4

You might want to look at this google list. It shows a ton of the main scanners, but most automated scanners fail to test every instance of exploits. Real human testing is best.


4

It sounds like you are mostly moving the problem around. The CI server used to have the credentials to push new installs to the Heroku server, now it's the deploy server. So the big question from me is - what is the difference in security between the CI service and the deploy server? Is one hosted externally? Is there a reason you trust one more than ...


4

Semi-automation is the answer. Human intelligence piloting automated tools is the best bet for maximizing test coverage and depth, not either or. What works: Smart people driving the tools. What fails: Everything else.


4

The short answer is: no. Here the long answer: The origin of fuzzing (or fuzz testing) is sending random data or slightly random data (i.e. sticking to a certain format or mutating something valid). The goal of fuzzing is usually to provoke an application crash. This crash can then be analyzed with debuggers or memory monitoring tools (i.e. Valgrind) to ...


4

It is important to understand that security assessment methods can use either black-box or white-box methods, and can be based upon either automated or manual methods. All 4 combinations are possible (e.g., automated black-box pentesting tools; manual black-box pentesting; automated source code scanners; manual source code review). Also, it is important to ...


3

Relying only on automated vulnerability scanning to vet the security of most applications is woefully inadequate. Why? Because automated tools will miss vulnerabilities (type II errors/false negatives). The uglier implication of this question is the application’s security is important yet it was ignored during development.


3

You have 2 points that can get compromised: git repository access and the CI service. Are you using CI SaaS, because what is the difference if your deploy server or your CI machine get compromised? They can both push code. If you have a CI service that is remote, you might as well build on your deploy server and push that actual build to the CI ...


3

I'm not aware of any publicly available toolsets for this at the moment, but there's been a couple of interesting white-papers and postings recently on the general security dangers of cursors Two from David Litchfield here and here and an interesting blog posting from Pete Finnigan here


3

There are two types of web-based, website security scanners that I am currently aware of: Ones that look for website and web application security defects Ones that look for malware hosted on your website Qualys provides services for both that are fairly standardized, cheap (for what you get), and run-of-the-mill. None of their scanning is very advanced ...



Only top voted, non community-wiki answers of a minimum length are eligible