Friday, 31 August 2012

Fun at UNI


When I was at uni one of my favorite game was to mess around with computers...

This is a list of my favorite games:


  • "the toaster": during a course, ssh to all the systems and run eject in the same time on all of them. 
  • "computers are slow": instead of running Matlab on my system (which is really resources consuming), I always connected to another system to run it and keep some CPU on mine.
  • "fork bomb": a classic
  • ".bashrc": as soon as someone turned his head, chmod 777 his bashrc and modify it later: 
    • add alias (ls=sl, cd='echo "NO"'): a good way to learn how to use \command to avoid aliases
    • add exit
    • put some ASCII ART love and unicorns
  • ...


What about you? what was your favorite game?

Monday, 13 August 2012

The 10 client-sides you're vulnerable to...

This was a test...

I can't resist this kind of titles and always go and read the x things...

  • the 10 linux distributions for pentest;
  • the 5 secrets of secure development;
  • the 6 ways to improve your skills
  • ...
I was just wondering how many people were like me...

Tuesday, 7 August 2012

Will QA change web penetration testing?


First, let's go back a little and think about the 2 main limitations of web scanners:
  • coverage: it's really hard to write a spider that will cover a full website, you need to write a tool that will understand a website and know exactly what to do and what data to submit (email when an email address is expected, name when an name is expected...)
  • scanner quality: it's really hard to write a web scanner that will avoid false positive and won't provide any false negative. It's particularly hard on production systems where error messages are/should be turned off, you often need to apply some crazy logic to find if a bug is there. 
Based on that, we can see that QA has it easy...
  • a set of tests providing all the requests for all the stories in the application. Basically,serious (agile) development teams test each functionality with a correct data set. QA can use this data set to replay request and fuzz the application and compare a "working" response to a "fuzzed" response... web scanners don't have that by default.
  • errors messages are turned on. If you manage to find suspicious cases you will get error messages with all the details... You just need to grep... no crazy logic needed.
Based on that, it's way easier to write a "security scanner" dedicated to QA than a "security scanner" for normal websites. You can even do things that most web scanners won't try since you will have error messages... For example, you can test for directory traversal using ../../../../../etc/shadow, that way you are likely to get error messages with "Access denied" and you know for sure that there is something wrong. Same for SQL injections, you just need to break the syntax and look for error messages instead of trying to apply some insane logic detection.

I'm not saying that web penetration testing will be replaced by QA or become a sub-part of it... but there is a chance that some companies split their budget between security during QA and penetration testing.

If you talk about it with people selling Web Scanner, they will tell you that their tools can memorize "stories" in the application, however, I don't see many people doing it and why should they re-do something that testers already did?

If you're interested by QA and security, make sure you check out my training on Test-Driven Security at OWASP New-Zealand : https://www.owasp.org/index.php/OWASP_New_Zealand_Day_2012#Training