Security and .Net Programming

.NET is a Java competitor from M$. It is also cross-platform, compiles to virtual machine code. During run-time is Just In Time compilation. So the source code compiles most of the way and goes the rest of the way when you run the program.

Security

Security aspects: secret data must be kept secret. Data I want to protect is confidential. Some data can be readable by many, but not writable. I want to protect the integrity of that data. Sometimes I don’t want to leave a paper trail for the feds. That’s non-repudiation. Data must also be accessible to me when I need it.
so to ensure all of that, I have authentication and logging. The Authorization and authentication protects confidentiality and integrity. Hashing also helps protect integrity. Encryption. logging for non-repudiation (have i got ths term backwards?). And redundancy keeps stuff available.
Now we’re talking about why we should care. Firewalls are no substitute for proper design, etc. I can’t even believe that people would think they didn’t need to worry about this if they were writing network applications.
.Net has it’s own sandbox concept called CAS: code access security. It is really similar. Code gets permissions based on origin and you can say how much you trust it, etc.
How about security for the developer? You need to figure out which permissions that your code will need. Communicate your permission requirements. Make the documentation machine readable. (Is this built-on/for free?)
What about for the admin? What permissions should the code get? What’s the source of this code? How much do i trust the source? Check the hash and the signature (x 509 or strong name (I don’t know what that means, but ok))
there are some pre-defined permissions. They can let you at some resources.
This talk is really intense for this group. I wonder if anybody in this room is a .net programmer.
ok, so you might want to access the printer or to skip verifying stuff. Full trust allows everything. Be careful. Did she just say that Microsoft must have full trust at all times? Isn’t that a huge issue?
So one spot to attack is input validation: Cross-scripting (XXS), SQL Injection, buffer overflows, canonization attacks. Double check everything!
Validate input against XXS:Cross Site Scripting. Lookout for javascript in image tags and weird html tags. Look out for .. in urls. Blackhats might be trying to get into forbidden directories.
The speaker is now warning us not to try this on other people’s websites, lest we become blackhats.
She is further warning us to make sure things are escaped and sanitized. And now the whiteboard has suddenly collapsed on my dog. Who seems ok. Um, so make sure html doesn’t get executed. And check your SQL. Is this actually a string? Is this way too long? Ironically, she’s going on great length about buffer overflow. Great, great length.
Now it’s canonicalization attacks, which is the thing where you need to use a full path or else somebody might be evil.
Ok, in summary: check all your input. know what you expect. check fr it. check for weird input. She’s asking somebody to describe what a regular expression is. I don’t know how to define this. She’s giving us an example. I don’t know if the point is to look out for regular expressions lurking in input or telling us to be smart with our regex. Ok, it’s the latter. Be precise.
Um, yeah obviously do all of this on the server side.

Session management

http is stateless. so fake states with cokies (um, be careful with that), encrypt the authentication cookie with SSL. There must be timeout.
Um, I’m going to skip out before everybody else eats all the food.