views:

399

answers:

6

I am a web developer that is very conscious of security and try and make my web applications as secure as possible.

How ever I have started writing my own windows applications in C# and when it comes testing the security of my C# application, I am really only a novice.

Just wondering if anyone has any good tutorials/readme's on how to hack your own windows application and writing secure code.

+2  A: 

Apart from all the obvious answers to prevent buffer overflows, code injection, session highjacking et. al. you should find somebody else to check your code/software because you can only think about ways to hack your software that you know how to prevent. Only because you can’t find a way to hack your own software that doesn’t mean that nobody else can.

Bombe
A: 

To secure your win form application open it and try to do everything that lambda user shoudn't do! I explaine myself.

If you say enter yes or no try with A-Z 0-9 because thats what some user do to try to find some stacktrace that could be interesting. So put validators everyware.

Beware of connection to databases but if you come from web dev you should be more awared then me :)

The hardest part is to watch out about memory leak or stuff like that but that in big big apps or not well developped.

Polo
+4  A: 

The books by Michael Howard are a good starting point;

19 Deadly Sins of software security (with examples in several lanaguages)

Writing Secure Code

There's loads of links and interesting articles from Michael Howard's blog here

There's an interesting powerpoint presentation from Microsoft about threat assessment, risks and ASP here

Dominic
+2  A: 

This is something that is very difficult for you to do, and I think that you are approaching the problem from the wrong angle. If you are writing an application of any size then attempting to deal with security at the end, by looking for specific ways of breaking your own software, is almost impossible.

This is for a number of reasons. You already think about your software in a certain way. You think of specific ways of interacting with it, and you know how to get the best from it. You don't think about it in terms of ways to exploit it, and this is a hard thing to do with software that you are intimately familiar with.

Another problem is that the task by this point is too big to deal with. Any problems that you do find may open up any number of other problems. A system wide security check is nowhere near granular enough.

What you should be doing is thinking about security while you write the software. Learn the best practices, and consider each method and class that you write from a security perspective. This goes hand in hand with unit testing, try to consider what inputs could make this specific part of my program break. and then deal with them at that level.

After that I think its a matter of responding quickly to any security concerns that you are made aware of.

Jack Ryan
+1 me likes
baeltazor
+1  A: 

You could do much worse than reasing Ross Anderson's Security Engineering book. The first edition is downloadable a a PDF and is a good read. I haven't read the second edition, but I suspect it's better and has more goodies in it.

Do note, it is a book that explains how to build security in from the start, not how to break security, but the exposition of assorted security faults should give you a good idea for where to start looking.

Vatine
+1  A: 

Small things that I have come across through my own experience.

  • Do not use dynamic SQL, you are then vulnerable to SQL injection. Rather use SQL queries with parameters.
  • Do not have incrementing ids like user_id = 1, 2, 3 etc etc and then use that in a URL, something.aspx?user_id=1, i can then guess the next id and session hope. Same for accounts and what ever else is sensitive.
  • Watch out for XSS, (cross site scripting). If you accept user input and store it directly, make sure that they can't go insert alert() for their name or something.

This is by no means a complete list. Just the stuff that I have run into recently.

uriDium