Session 2 Objectives

1. Session 2 Objectives • Learn the basic concepts of web infrastructure and associated terminology. • Understand the risks that impact web infrastructure and the controls to mitigate them. • Gain the skills to assess the security posture of a web infrastructure and make management recommendations. • Apply security principles and best practices to a web infrastructure.

2. The Big Picture • Elements of the web infrastructure. • Some risks that impact the infrastructure.

3. Web primer Web: Series of computers connected to each other via a network (Internet) and use common set of languages. • Broadly speaking, web essentially is a series of clients (browsers) and servers (web servers) that talk to each other via an agreed upon protocol (http), display results in a common format (HTML) over a shared network (Internet). • The web client is essentially an application software, commonly known as a browser. Examples of browsers include Microsoft’s Internet Explorer, Mozilla’s Firefox, Apple’s Safari, etc.

4. Web primer Web: Series of computers connected to each other via a network (Internet) and use common set of languages. • Web clients perform the following key tasks: • Send requests to web servers • Use http or SSL to send requests • Receive response and render it on screen • Run mobile code (ActiveX, Java applets) sent by the server • In addition, web browsers can support other protocols like ftp to transfer files. Some of the newer browsers support transfer technologies like BitTorrent too.

5. Web primer Web: Series of computers connected to each other via a network (Internet) and use common set of languages. • Web servers receive the requests from the web browsers and respond via one of the following means: • Send a static page back to the browser • Forward the request to a web application to compose a response • Send mobile code to the browser to execute • Responses from web servers are typically in HTML format. Over the last few years, responses in XML format have become popular which are rendered by the browser for display. Also, for mini-browsers, the responses maybe in WML format.

6. Web primer Web: Series of computers connected to each other via a network (Internet) and use common set of languages. • Common web servers include open-source Apache, Microsoft’s IIS, etc. • Applications servers often receive the request from web servers and host the business logic to build a response. • They host the web applications • Communicate with the backend databases via ODBC/JDBC • Provide a robust support environment for the applications (clustering, redundancy, security, etc.) • Common application servers include IBM’s WebSphere, BEA’s WebLogic, etc.

7. Web primer Web: Series of computers connected to each other via a network (Internet) and use common set of languages. • Web browsers, web servers, application servers, and databases are key components of a web infrastructure.

8. Management concerns Concerns about operating system security typically include the following: • Maximizing the availability and performance company’s web sites to protect revenue and image. • Maintaining the integrity and confidentiality of employee and customer data passing through web applications. • Alleviating privacy concerns for employees and customers. • Keeping up with existing and upcoming security threats and implementing mitigating controls. • Having an effective backup, recovery, business resumption and a disaster recovery plan.

9. Risks and controls Web browsers: Client applications used by end users to request and receive responses from websites. • Web browsers are user’s front-end into web applications. • Web browsers have become another target for malicious users to attack others. Some of the risks associated with web browsers include: • Privacy concerns for end users • Attacks on session management • Risk of mobile code • Insecure security zones • Phishing scams

10. Risks and controls Privacy: Web browsers can lead to privacy concerns for end users. • Web browsers have features that improve browsing experience and convenience for web users. However, these can cause privacy concerns. • The “autocomplete” feature in some browsers like Internet Explorer remembers entries made by users on web pages, search engines, text boxes. • “History” feature within browsers maintains a history of websites visited by the user. Some even maintain a log of files transferred over the web.

11. Risks and controls Privacy: Web browsers can lead to privacy concerns for end users. • Many browsers remember a feature to remember userIDs and passwords for logging onto various websites. • Most browsers maintain a cache that contain local copies of web pages visited by users.

12. Risks and controls Privacy risks: • Anyone with physical access to the machine can gain a fairly detailed view of activities of the previous user. Controls: • Disable autocomplete, history, cache features – however, this comes at a loss of functionality. • Newer browsers come with “clean-up private data” upon exiting option which helps maintain privacy.

13. Risks and controls Session management: Web browsers have to maintain sessions with websites. • HTTP is stateless protocol – every transaction between the browser and the server is independent of each other. Subsequent transactions don’t know anything about previous transactions (state is not maintained). • This poses problems for applications that need state information to manage a session. • For example, it may authenticate a user in a transaction, and would need to remember the user is authenticated for subsequent transactions until the user logs out. • Web developers achieve session management via a couple of means: cookies and session IDs.

14. Risks and controls Session management: Cookies help maintain state. • Cookies are small data files that are given to a browser by a web application when a user first visits. • Every subsequent visit, the application checks if a cookie exists (and if so, its contents) and thus knows if a user has previously accessed the application and what was done in the previous transaction. • Cookies can be persistent (written to hard drive) or non-persistent (in browser memory). • Cookies can have expiration dates.

15. Risks and controls Session management: Cookies help maintain state. • Cookies can be secure (encrypted in transmission) or non-secure (not encrypted).

16. Risks and controls Session management: Session IDs help maintain state. • Session IDs are token numbers given to a client by a web application when a user first visits. • The session data associated with the user is stored on the server side (as opposed to cookies which are stored on client) and can be referenced via the session ID. • Every subsequent visit, the client provides the session ID to the application which checks the session store and thus knows if a user has previously accessed the application and what was done in the previous transaction.

17. Risks and controls Session management: Session IDs help maintain state. • Session IDs can be passed via the URLs or via hidden fields in the forms submitted.

18. Risks and controls Session management risks: • Cookies can manipulated by end users to elevate privileges or impersonate others. • Cookies can be sniffed/stolen leading to impersonation. • Session IDs maybe predictable allowing attackers to impersonate other users. • Session IDs may be sniffed. Controls: • Encrypt the contents of the cookies to prevent manipulation.

19. Risks and controls Controlscontd.: • Encrypt the contents of the cookies to prevent manipulation. • Implement checksums on cookies and/or session IDs to ensure they haven’t been tampered with. • Avoid storing authentication credentials in cookies. Server side storage of data is more secure. • Session IDs should be random preventing its prediction. • Use SSL or other encryption methods to prevent sniffing.

20. Risks and controls Mobile code: Code sent by a website to a browser for execution. • The functionality offered to users is greatly enhanced by mobile code sent by browsers. Else, a browsers would be able to mostly display static content only. • Besides scripting languages like JavaScript, web servers send executable code to browsers via two key technologies: Java applets and ActiveX. • Java applets are Sun’s technology whereas ActiveX is Microsoft technology. Both work conceptually similar, in that upon visiting a website, the code is sent to be loaded and executed by the browser.

21. Risks and controls Mobile code: Code sent by a website to a browser for execution. • However, Java applets and ActiveX have fundamentally security models. • Java applets use a “sandbox” model, wherein the code is restricted in terms the system resources it can access and system commands it can invoke. This prevents the code from doing any damage to the system. • ActiveX follows an “Authenticode” model, wherein the code can perform any action without any limitations, however, the code has to be digitally signed by the author thereby assigning accountability.

22. Risks and controls Mobile code risks: • Flaws have been identified that let Java applets to breach the “sandbox”. • End user is assigned the responsibility of determining whether to trust the signed ActiveX code. • Many unsafe ActiveX controls (programs, from various vendors) are marked “safe-for-scripting” (which allows them to be invoked by any malicious web page/e-mail). Controls: • Disable mobile code to the extent possible.

23. Risks and controls Controls: • Disable unsigned ActiveX and consider the same for signed ActiveX. • Allow mobile code to be executed only in from trusted websites.

24. Risks and controls Security zones: Browsers allow users to classify websites by their trust factor. • End users can have granular definitions of trust via security zones. • Typical zones include the following (in the order of increasing trust / decreasing restrictions) • Restricted sites • Internet sites • Local intranet sites • Trusted sites • Every zone can be further customized to specify who can run mobile code, who can download mobile code, whether to run code with / without prompting, etc.

25. Risks and controls Security zone risks: • Default zones (“Internet”) often aren’t tightly secured. For example, it allows ActiveX controls, Java, unsigned .NET components etc. Controls: • Review each configuration feature available in a zone and decide whether it should be allowed or not. • Follow the recommended “deny if not allowed” approach rather than the “allow if not denied” approach.

26. Risks and controls Phishing: Internet-based scams that targets end-users personal/confidential information. • Scammers “ph-ish” (fish) for userIDs, passwords, bank account numbers, social security numbers, etc. from unsuspecting end users via a variety of techniques. • Techniques include sending social engineering via spoofed e-mails that seem to come from legitimate sites asking for confidential information, fake websites that capture userIDs and passwords etc.

27. Risks and controls Phishing risks: • These attack lead to fraudulent transactions, identity theft, disclosure of sensitive information, etc. Controls: • User education is the key to protection against phishing attacks. • Effective spam control can protect users against phishing e-mails that lead them to fake websites. • Newer browsers have features that warn users against possible phishing websites.

28. Risks and controls Web servers: Web servers receive requests from browsers and send back responses to the same. • Web servers are key to a web site’s availability and need to strongly protected. • Some of the risks/attacks against web servers include: • Insecure operating systems • Flaws with web server software • Flaws with add-on components

29. Risks and controls Operating system: Web server software resides on operating systems that have to be secure. • As mentioned in chapter 7, without a secure operating system nothing residing on it can be considered secure. • Web servers often reside in the DMZ instead of internal network (to allow outsiders access to websites). • Hence, they are much more exposed to external attacks, making the need to secure the OS even higher than OS on machines that are within the network.

30. Risks and controls Operating system risks: • Chapter 7 covered OS risks in detail. In general, default accounts, weak file and directory permissions, insecure services, missing security patches etc. increase the risk of the OS (and hence web server) compromise. Controls: • Evaluate the need for each service installed on the OS. Unnecessary services should be turned off. • Assess the patch deployment process. All necessary patches should be implemented.

31. Risks and controls Controls contd: • Review authentication methods, user accounts and their privileges. Ensure quality user ID and password management techniques are used. • Determine the legitimacy of trust relationships. • Ensure core OS files are baselined and are protected. • Evaluate the need and security of all file shares. • Determine if additional controls like anti-virus, personal firewalls, and intrusion prevention systems are in place. • Review all scheduled jobs and their controls.

32. Risks and controls Web server software: Web server software receives inputs from browsers and responds to them. • Web server software listens on port 80 for http traffic from browsers (port 443 for SSL encrypted traffic). • Web server software often works with databases or other application servers to compose responses to the browsers. • The configuration of the software can add several risks to web security. • Web server software often comes with “add-on components” that add programming and/or administrative functionality.

33. Risks and controls Web server software risks: • Web server software runs as a user on the OS. Some installations define this user with high privileges (out of choice, ignorance, or necessity). This increases the fallout associated with a compromise. • Many default installations come with sample scripts and applications preloaded. These are often exploited by attackers. For example, IIS had a showcode.asp sample code that was often used by intruders. • At times web server software provides detailed error messages that helps attackers footprint the system.

34. Risks and controls Web server software risks: • Web server software may allow for “directory traversals” that allows users to navigate outside of directories that store web pages and read sensitive files. • In addition to web server software, the add-on components are often susceptible to attacks like buffer overflows. Controls: • Keep web server software patched. • Minimize privileges associated with web server software. • Remove all sample scripts, applications etc.

35. Risks and controls Controls: • Remove sensitive data from source codes. • Install web content on a drive that is separate from the drive that contains the OS files. • Evaluate the need for each service installed on the OS. Unnecessary services should be turned off. • Assess the patch deployment process. All necessary patches should be implemented. • Unused add-on components should be removed or disabled. The rest should be patched regularly.

36. Risks and controls Web applications: Web applications reside on web and/or application servers and provide end users with various functionality. • Web applications can be compromised via a variety of ways unless they are programmed really carefully. • Some of the risks/attacks against web applications include: • Improper input validation • Cross-site scripting attacks • Buffer overflow attacks • SQL injection attacks • Improper error handling

37. Risks and controls Input validation: Web applications implement controls to ensure the input entered is valid. • Web applications expect valid input – that is, it is of correct length, right type (text vs integer), etc. • Developers often insert edit checks via JavaScript that is executed on the client side. • However end users can always modify these checks (since they reside on client side) to bypass them and submit wrong inputs to the application. • At times developers will implement edit checks on the server side. However, they have to be carefully designed to avoid being bypassed or to ensure malicious input is filtered out.

38. Risks and controls Input validation risks: • Client side input validation should not be relied upon. • Use server side validation checks as far as possible. • Canonicalize the input (decode all input to simplest form) before processing the input to avoid attacks that use encoded characters. • Educate developers about various attacks and provide secure programming training.

39. Risks and controls Cross-site scripting (XSS) attacks: Code injection by malicious users into web pages viewed by web users. • Web browsers receive mobile code (say JavaScript) from web servers all the time. • This (JavaScript) code is executed in the browser and has access to all objects (cookies, web pages, etc.) from that web server. • This access isn’t a problem since the (JavaScript) code is provided by the same web server that provided the objects too. • What happens if malicious user is able to provide the JavaScript code to the web server, that gets sent to the web browser?

40. Risks and controls Cross-site scripting (XSS) attacks: Code injection by malicious users into web pages viewed by web users. • If so the browser will execute the malicious JavaScript code as if belongs to the web server browser and allows access to all the objects. What can this access do? • It can copy the user’s cookie (for that web site), run local commands (if the web site is trusted), or subject user to phishing attacks (steal userID and passwords).

41. Risks and controls Cross-site scripting (XSS) attacks: Code injection by malicious users into web pages viewed by web users. • So how is malicious code inserted into web servers? This occurs via web applications that accept user input without validation. For example • newsgroups web pages may allow a user to enter postings (which could contain malicious code) and these postings are fed back to other users to read, subject them to XSS attack. • Social engineering attempts wherein user is convinced to click on a malicious URL that leads to an XSS vulnerable website.

42. Risks and controls Cross-site scripting (XSS) attacks: Code injection by malicious users into web pages viewed by web users. • Several well known websites have been subject to XSS attacks/vulnerabilities: • Charles Schwab website • Hotmail website • cbs.com • news.bbc.co.uk • Paypal website

43. Risks and controls Cross-site scripting (XSS) attack risks: • XSS vulnerable websites can lend its users to a variety of risks including attackers obtaining their credentials, access to their financial accounts, disclosure of sensitive data etc. Controls: • XSS vulnerabilities are bountiful and need a careful review of all code to identify them. • Provide training to web application developers in regarding XSS and secure programming. • Stringent input validation is required by web applications before accepting any input from users.

44. Risks and controls Controls contd.: • Malicious characters in user input should be removed or encoded them (so that the browser doesn’t interpret is as executable code). • Disable scripting on browser so malicious code doesn’t execute. • Allow only trusted websites to execute code.

45. Risks and controls Buffer overflows: Attack wherein malicious input spills into sensitive portions of memory compromising applications. • Buffer overflows were covered in detail in application security chapter. Buffers are memory locations allocated by programmers to store user’s inputs. • Attackers may provide malicious input that runs past the size of the buffer. • Extra input could spill into sensitive portions of memory with results ranging from nothing happening, to application crashing, to a complete compromise. • Web server software are often impacted by buffer overflows attacks. • E.g. Code Red virus attacked IIS web servers.

46. Risks and controls Buffer overflows: Attack wherein malicious input spills into sensitive portions of memory compromising applications. • In addition, web applications that use susceptible third-party libraries can also be impacted. • E.g. Microsoft’s GDIPlus library was target of buffer overflows.

47. Risks and controls Buffer overflow risks: • Impact of buffer overflow ranges from application failing its execution, to its crash, to running of malicious code of attacker’s choice resulting in complete compromise. Controls: • Enforce boundary checks before accepting inputs. Use compilers that warn of potential overflow conditions. • Educate programmers in safe programming practices. • Use languages like Java (instead of C/C++) that don’t let input easily run past its buffer allocation. • Apply latest patches for third-party libraries.

48. Risks and controls SQL injection: Attack wherein malicious SQL commands are passed into web applications via user inputs. • Web applications with back-end databases are often susceptible to these attacks. • These applications convert user supplied input into SQL commands that are processed by the database. • Attackers can craft special input that make the SQL commands malicious in nature. • The database processes these malicious SQL commands and end up disclosing sensitive data or running sensitive database commands.

49. Risks and controls SQL injection: SQL injection attack example. • Consider, a web application, that allows users to type in a keyword to search a particular product type by asking: Product keyword: antique • Say, the resulting SQL executed by the database is: SELECT product FROM product_table WHERE product_description like ‘%antique%’; • This query results in showing all products from the product_table that have the keyword ‘antique’ in it.

50. Risks and controls SQL injection: SQL injection attack example contd. • Now consider, if the user provides the following special input: Product keyword: antique%’; DROP table_w_sensitive_data;-- • The resulting SQL executed by the database then is: SELECT product FROM product_table WHERE product_description like ‘% antique%’; DROP table_w_sensitive_data; --%’; • This results in display user IDs and password hashes and deletion of a table!!