Presentation on theme: "You know you shouldn’t have done that. Richard Manion."— Presentation transcript:
You know you shouldn’t have done that. Richard Manion
Who am I? (Not just an existential question)
Who are we?
Leave with this! You matter!! Don’t trust the client. Sanitize your inputs. Leave the viewstate MAC on. Use the machine.config for enforcement. Build patterns.
Why should you care? 430 “Software Developers, Applications,” or “Computer Programmer” in Dubuque 50/50 J2EE vs Java
Why should you care? ~200.Net Developers in Dubuque
Why should you care? How many “Security Professionals and Network Architects” does the OOH report?
Why should you care? 1,890 “Software Developers, Applications” in the DSM metro (OOH) 50/50 J2EE vs Java
Why should you care? ~900.Net Developers in DSM
Why should you care? 630 Security Professionals and Network Architects 78% of Security professionals are in “Identity Management” ~3400 App SANS certified application testers vs ~32000 certified generalists (~10%) ~13 Application Security Specialists in Des Moines
Why should you care? 1:71
Why should you care? 1:71
Why should you care?
Do you think your security department knows what you are doing?
Why show errors? Do they improve the user experience? – They aren’t pretty – They aren’t useful – They aren’t “friendly” Do you need them in production? – Is that where you are logging errors? – Can you just change it when you need it? – Is this just a screw up?
So…let’s not screw it up Set the customErrors behavior in your machine.config Use allowOveride=False Bonus: Uniformity in error messages When debugging – Set allowOveride=True – Change one web/app config – Change it back
Don’t trust the client Why are you using query strings in a dotNet app? Why are you storing data in the cookie? And also: Why did you turn off MAC in viewstate?
ViewState MAC: How.Net knows if the ViewState changed The ViewState is not encrypted Why are you storing data in ViewState? – Easy way to go from page to page Why are you changing the ViewState at the Client
Don’t disable MAC Don’t store sensitive stuff in the ViewState ViewState
If you cleaned it up on the client, and it was dirty when you got it, then…. If you can’t limit it, escape it – If you escaped it on the client and it isn’t escaped now, then…
How do you store passwords safely?
How do you store passwords safely? On the Client rnd1 = SHA1(64charsofSalt + Password) A couple hundred times.. Rnd1=SHA1(Rnd1) On the server RND2 = SHA1(64charsofSomeAppSpecificSalt + Rnd1 + 64charsofSomeUser SpecificSalt) A couple hundred times rnd2=SHA1(rnd2) Where AppSpecificSalt is stored in a different place then User Salt (i.e. not in the DB).
How do you store passwords safely? Some security folks still won’t like this. Requiring processing power is the enemy of password cracking. Never encrypt a password. Don’t assume some other app is storing it safely unless you asked. You shouldn’t need to reuse that password-- think about your architecture.
My app isn’t important Your users reuse their passwords. You are morally obligated to protect that password like it is the password to the most secure thing it is being used for…because that is its value to the user. You don’t know what that is, but it is likely at least a bank account. Your user’s stupidity is your responsibility in this case.
Encrypting Data in.Net Hashing is not Encoding is not Encrypting Use AES for Encryption with a 128-bit or better key You don’t need to know your IV, it shouldn’t be IVIVIVIVIVIVIVIV Encrypt(strA) != Encrypt(strA) if you did it right.
Storing Encryption Keys “Different Places” File system, DPAPI, Registry, Database Store things in two places Don’t put things in files that are in your applications home folder (beside you aspx) Why, oh, why would you put your encryption key with your data?
Hard things to do: Writing encryption/hashing algorithms Authentication Authorization PRNG- Random numbers