Web Security Prepared From The Open Web Application Security Project WWW.OWASP.COM by David Wilczynski

1. Web SecurityPrepared From The Open Web ApplicationSecurityProjectWWW.OWASP.COMbyDavid Wilczynski The Dangers of which Programmers Should Be Aware

2. HTTP, Web Browsers, GUIs • 2nd Tier Application on WebServer communicating with 1st Tier browser are usually on separate machines. • You can’t be sure the input is coming from a trusted user or even the user you are dealing with. • The HTTP you expect from the client may be “spoofed” by an intruder. • Ten Most Critical Web Security Vulnerabilities

3. 1. Unvalidated Input • Information from web requests is not validated before being used by a web application. • Attackers can use these flaws to attack backend components through a web application.

4. 2. Broken Access Control • Restrictions on what authenticated users are allowed to do are not properly enforced. • Attackers can exploit these flaws to access other users' accounts, view sensitive files, or use unauthorized functions.

5. 3. Broken Authentication and Session Management • Account credentials and session tokens are not properly protected. • Attackers that can compromise passwords, keys, session cookies, or other tokens can defeat authentication restrictions and assume other users' identities.

6. 4. Site Scripting (XSS) Flaws • The web application can be used as a mechanism to transport an attack to an end user's browser. • When a user is tricked into clicking on a malicious link or submitting a specially crafted form, the injected code travels to the vulnerable web server, which reflects the attack back to the user’s browser. The browser then executes the code because it came from a ‘trusted’ server.

7. 5. Buffer Overflows • Web application components in some languages that do not properly validate input can be crashed and, in some cases, used to take control of a process. • These components can include CGI, libraries, drivers, and web application server components.

8. 6. Injection Flaws • Web applications pass parameters when they access external systems or the local operating system. • If an attacker can embed malicious commands in these parameters, the external system may execute those commands on behalf of the web application.

9. 7. Improper Error Handling • Error conditions that occur during normal operation are not handled properly. • If an attacker can cause errors to occur that the web application does not handle, they can gain detailed system information, deny service, cause security mechanisms to fail, or crash the server.

10. 8. Insecure Storage • Web applications frequently use cryptographic functions to protect information and credentials. • These functions and the code to integrate them have proven difficult to code properly, frequently resulting in weak protection.

11. 9. Denial of Service • Attackers can consume web application resources to a point where other legitimate users can no longer access or use the application. • Attackers can also lock users out of their accounts or even cause the entire application to fail.

12. 10. Insecure Configuration Management • Having a strong server configuration standard is critical to a secure web application. • These servers have many configuration options that affect security and are not secure out of the box.

13. 1. Unvalidated Input • Attackers can tamper with any part of an HTTP request, including the url, querystring, headers, cookies, form fields, and hidden fields, to try to bypass the site's security mechanisms • Attacks include: forced browsing, command insertion, cross site scripting, buffer overflows, format string attacks, SQL injection, cookie poisoning, and hidden field manipulation

14. Parameter Specification • Data type (string, integer, real, etc…) • Allowed character set • Minimum and maximum length • Whether null is allowed • Whether the parameter is required or not • Whether duplicates are allowed • Numeric range • Specific legal values (enumeration) • Specific patterns (regular expressions)

15. Example - Scenario • You are to populate a list with accounts provided by the back-end (3rd tier) system. The user will choose an account, choose a biller, and press next. • Wrong WayThe account select option is read directly and provided in a message back to the backend system without validating that the account number is one of the accounts originally provided by the backend system.

16. A Good Way acc = session.getParameter('payeelstid‘); if account.inList(acc) backend.performTransfer(acc); else error();

17. A Better Way int payeeLstId = session.getParameter('payeelstid'); accountFrom = account.getAcctNumberByIndex(payeeLstId); The above field cannot be tampered with.

18. Data Validation Strategies • There are four strategies for validating data, and they should be used in this order: • Accept known good • Reject known bad • Sanitize • Accept without validation

19. Accept known good (Best) • If you expect an integer, check for one.

20. Reject known bad If you don't expect to see characters such as %3f or JavaScript or similar, reject strings containing them: public String removeJavascript(String input) { Pattern p = Pattern.compile("javascript", CASE_INSENSITIVE); p.matcher(input); return (!p.matches()) ? input : ''; }

21. Sanitize • Eliminate or translate characters in an effort to make the input "safe." • This does not work well in practice, as there are many, many exceptions to the rule. public String quoteApostrophe(String input) { return str.replaceAll("[\']", "’"); }

22. No validation account.setAcctId( getParameter('formAcctNo'));

23. 2. Broken Access Control • Access control, or authorization, is how a web application presents content and functions to some users and not others. • These checks are performed after authentication, and govern what ‘authorized’ users are allowed to do. • Few use an access control matrix to define the access control rules.

24. Principle of least privilege • Far too often, web applications run with excessive privileges. • Never use “Administrator”, “root”, “sa”, “sysman”, “Supervisor” to run the application.

25. Access Control Lists • Many access controls are out of the box insecure. • For example, the default Java 2 file system security policy is “All Permission” grant codeBase "file:${{java.ext.dirs}}/*" { permission java.security.AllPermission; };

26. Client-side authorization tokens • Many web application developers are keen to not use session storage – which is misguided when it comes to access control and secrets. • So they revert to using the client’s state, either in cookies, headers, or in hidden form fields.

27. 3. Broken Authentication and Session Management • Handling user authentication and managing active sessions. • Can be undermined by flawed credential management functions, including password change, forgot my password, remember my password, account update, and other related functions. • Because of “walk by” attacks, all account management functions need reauthentication even if the user has a valid session id.

28. Best Practices • Authentication is only as strong as your user management processes, and in particular the user issuance and evidence of identity policies. • Use the most appropriate form of authentication suitable for your asset classification. • For example, username and password is suitable for low value systems such as blogs and forums • SMS challenge response is suitable for low value e-commerce systems (in 2005), • transaction signing is suitable for high value systems such as high value e-commerce, banking and trading systems.

29. Best Practices (cont). • Re-authenticate the user for high value transactions and access to protected areas (such as changing from user to administrative level access) • Authenticate the transaction, not the user. Phishers rely on poorly implemented user authentication schemes • Passwords are trivially broken and are unsuitable for high value systems. Any password less than 16 characters in length can be brute forced in less than two weeks, so set your password policy to be reasonable.

30. More on Passwords • Train your users to use suitable passwords. • Allow your users to write down their passwords as long as they keep them safe • Encourage pass phrases instead of passwords • Relax password expiry requirements upon the strength of the password chosen—easy passwords should have an expiry of 30 days, and good ones probably do not need a hard expiry limit, but a gentle reminder after (say) 90 days instead. • Modern browsers offer users the ability to manage their credentials by storing them insecurely on their computer.

31. Remember Me • On public computers, “Remember Me?” functionality, where a user can simply return to their personalized account can be dangerous. • For example, in Internet Cafes, you can often find sites previous users have logged on to, and post as them, or order goods as them (for example with eBay).

32. Session Management To ensure that • authenticated users have a robust and cryptographically secure association with their session • enforce authorization checks • prevent common web attacks, such as replay, request forging and man-in-the-middle attacks • Best practice is to not re-write the wheel, but to use a robust, well-known session manager.

33. Permissive Session Generation • Many web application frameworks will simply issue a new requestor a valid session ID if one does not exist. • This is called “permissive session generation” • Coupled with some forms of phishing and an associated lack of authorization, this attack can be devastating.

34. How to determine if you are vulnerable • Open a fresh browser to connect to a protected page or action deep in the application. • If a new session ID is generated and the page works, the authorization is falsely assuming the validity of the session variable.

35. How to protect yourself • When starting a fresh session object for a user, make sure they are in the “logged off” state and are granted no role. • Ensure that each protected page or action checks the authentication state and authorization role before performing any significant amount of work, including rendering content. • Ensure that all unprotected pages use as few resources as possible to prevent denial of service attacks, and do not leak information about the protected portion of the application

36. Session Time-out • Session tokens that do not expire on the HTTP server allow an attacker unlimited time to guess or brute-force a valid authenticated session token. • If a user's cookie file is captured, then an attacker can use these static-session tokens to gain access to that user's web accounts. • A problem especially in environments where computers are shared.

37. Session Hijacking • When an attacker intercepts or creates a valid session token on the server, they can then impersonate another user. • Session hijacking can be mitigated partially by providing adequate anti-hijacking controls in your application. • The easiest type of web application to hijack are those using URL based session tokens used in Internet cafes.

38. 4. Cross-Site Scripting (XSS) Flaws • An attacker can send a malicious script to an unsuspecting user. A variant of the Trojan Horse. • Often, the end user’s browser has no way to know that the script should not be trusted, and will execute the script. • Because it thinks the script came from a trusted source, the malicious script can access any cookies, session tokens, or other sensitive information retained by your browser and used with that site.

39. XSS: Stored and Reflected • Stored attacks are those where the injected code is permanently stored on the target servers, such as in a database, in a message forum, visitor log, comment field, etc. • The victim then retrieves the malicious script from the server when it requests the stored information.

40. Reflected Attacks • Injected code is reflected off the web server, such as in an error message, search result, or any other response that includes some or all of the input sent to the server as part of the request. • Reflected attacks are delivered to victims via another route, such as in an e-mail message • When a user is tricked into clicking on a malicious link or submitting a specially crafted form, the injected code travels to the vulnerable web server, which reflects the attack back to the user’s browser. • The browser then executes the code because it came from a ‘trusted’ server.

41. 5.Buffer Overflow • Attackers use buffer overflows to corrupt the execution stack of a web application. • By sending carefully crafted input to a web application, an attacker can cause the web application to execute arbitrary code - effectively taking over the machine. • Attackers have managed buffer overflows in a staggering array of products and components. • Sending large inputs can cause the web application or the back-end database to malfunction.

42. Stack Overflow • The source buffer contains arbitrary attack input, and the destination buffer is too small to contain the attack input. The second buffer is on the stack, near the function return address on the stack. • The faulty code without checking size, copies the hostile data into the second buffer, obliterating the second buffer and the stack’s return address. • When the function returns, the CPU unwinds the stack frame and pops the faulty return address from the stack, which now points to attack code. • The attack code is executed instead of returning to the application’s previous caller

43. Heap Overflow • A heap is an area of memory allocated by the application run time to store locally declared variables. function foo(char *bar) { char thingy[128]; ... } • bar is passed via the stack, whereas thingy is allocated on the heap. The overflow possibilities are exploitable just like stack overflows. • Validate user input to prevent overlong input and check the values to ensure they are within spec (i.e. A-Z, a-z, 0-9, etc).

44. Integer Overflow • When an application takes two numbers of fixed word size and perform an operation with them, the result may not fit within the same word size. • For example, if two 8 bit numbers 192 and 208 are added together and stored into another 8-bit byte, the result will simply not fit into the 8 bit result.

45. How to protect yourself • .NET: Use David LeBlanc’s SafeInt<> C++ class. • If your compiler supports it, change the default for integers to be unsigned unless otherwise explicitly stated. Use unsigned whenever you mean it. • Use range checking if your language or framework supports it. • Be careful when using arithmetic operations near small values, particularly if underflow or overflow, signed or other errors may creep in.

46. 6. Injection Flaws • Injection flaws allow attackers to relay malicious code through a web application to another system. • These attacks include calls to the operating system via system calls, the use of external programs via shell commands, as well as calls to backend databases via SQL (i.e., SQL injection). • Whole scripts written in perl, python, and other languages can be injected into poorly designed web applications and executed. • Any time a web application uses an interpreter of any type there is a danger of an injection attack.

47. Immediate Reflection • The victim is encouraged/forced to a vulnerable page, such as a link to cute kittens, a redirect page to “activate” an account, or a vulnerable form which contains an improperly sanitized field. • Once the user is on the vulnerable destination, the embedded reflection attack launches the attacker’s payload. Even though GET requests need to be less than 2 or 4 KB in size, this has proved ample . • Nearly all phishing attempts are like this.

48. Stored Injection Attack • The injection occurs at a previous time and users are affected at a later date. • The usual type of attack are blog comments, forum, and any relatively public site which can be compromised in some fashion.

49. Protecting against Reflected Attacks • Strong input validation should remove suspicious characters. • In ASP.NET, you should add this line to your web.config: <pages validateRequest="true" /> in the <system> </system> area.

50. Protecting against stored attacks With unclean sources, output validation is required. • ASP.NET: In web.config – validateRequest to be true and use HTTPUtility.HTMLEncode() for body variables. • PHP: Use htmlentities(), htmlspecialchars(), for HTML output, and urlencode() for GET arguments. • JSP: Output validation is actually very simple for those using Java Server Pages - just use Struts, such as using <bean:write ... > and friends: • Good: <html:submit styleClass="button" value="<bean:message key="button.submitText /> "/> • Bad: out.println('<input type="submit" class="button" value="<%=buttonSubmitText%>" />');