Security testing

4,010 views

Published on

0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
4,010
On SlideShare
0
From Embeds
0
Number of Embeds
916
Actions
Shares
0
Downloads
0
Comments
0
Likes
3
Embeds 0
No embeds

No notes for slide
  • Security scanner or firewall application “ patch and penetrate” model since 1990 Security in all the phases of SDLC Early detection of bugs; educated devs and qas about security issues, new tools, libraries and languages How much security is needed; PCI DSS; PA DSS Testing from attacker view also
  • Require accurate documentation of the app; technical specification also Be aware of the used tools limitations Verify every possible section of app logic and all use case scenarios to expose all the vulnerabilities Security team should have the code while performing review to detect vulnerabilities that could be missed during black box testing Metrics; more training is needed; number of issues tracked should go down
  • Analyze the doc, interview the designers and business owners Av: - early in SDLC; team work; flexible; not supporting technology needed; variety of situations that can be used Disav: time consuming; no supporting doc; requires human thought and skills 2. = risk assesment for the app Av: practical attacker’s view; early in SDLC; flexible Disav: good threat model <> good secure code
  • XSS flaws occur whenever an application takes untrusted data and sends it to a web browser without proper validation and escaping. XSS allows attackers to execute scripts in the victim’s browser which can hijack user sessions, deface web sites, or redirect the user to malicious sites
  • Security testing

    1. 1. Security TestingStefana BotezatuMay, 2013
    2. 2. Security Testing•Generalities•OWASP - Top Ten Vulnerabilities
    3. 3. Generalities• What is Security Testing & Why is needed?• When & What to test?• Types of Security Testing• Principles of Security Testing• Security Testing Techniques
    4. 4. All begin from here …
    5. 5. What can cause trouble?
    6. 6. What is Security Testing & Why is needed?• Security Testing is the process to determine that an InformationSystem protects data and maintains functionality as intended.• Security Testing is needed: To ensure Input Data Validation To ensure Control on Internal Processing To ensure Message Integrity To ensure Output Data Validation
    7. 7. When to test?• To prevent security bugs from appearing in production applications,SDLC should be improved to include security on each of its phases.
    8. 8. What to test?• A common mistake when testing for security is to conduct tests related onlyto technology or software itself.• An effective testing program should test: People - to ensure that there is adequate education and awareness; Process - to ensure there are adequate policies and standards andpeople know how to follow the policies; Technology - to ensure that the process has been effective in it’simplementation.
    9. 9. Types of Security Testing• Security Auditing Direct inspection of the application developed and Operating System Code Walk-through• Security Scanning Scanning and verification of system and applications Auditors inspect and try to find weaknesses in Operating Systems, applications,network(s)• Vulnerability Scanning Scanning app for all known vulnerabilities Generally performed using vulnerability scanning software
    10. 10. Types of Security Testing• Risk Assessment Interviews, discussions, analysis around same thing Helps in finding out and preparing possible back-up plan for any type of potentialrisk• Ethical Hacking Forced intrusion of an external element into the system and application under test• Posture Assessment and Security Testing Combination of Security Scanning, Risk Assessment and Ethical Hacking• Penetration Testing Tester that tries to forcibly access and enter the application under test Using of other applications or combinations of loopholes present in applicationunder test
    11. 11. Principles of Security Testing• There is no Silver Bullet• Think Strategically, Not Tactically• SDLC is the King• Test Early and Test Often• Understand the Scope of Security• Develop the Right MindsetTIMERISKLEVELVulnerability ismade publicA securityvulnerability isdiscoveredVulnerability isknown to thevendorVendor notifiesits clients(sometime)Securitytools areupdatedA patch ispublishedExistenceof patch iswidelyknownPatch isinstalledin allsystemsaffected
    12. 12. Principles of Security Testing• Understand the Subject• Use the Right Tool• The Devil is in Details• Use Source Code when available• Develop Metrics• Document the Test Results
    13. 13. Security Testing Techniques• Manual Inspections & Reviews• Threat Modeling• Balanced Approach
    14. 14. OWASP – Top Ten Vulnerabilities• OWASP – Open Web Application Security Project• Is a not-for-profit worldwide charitable organizationfocused on improving the security of application software• More info: http://www.owasp.org
    15. 15. OWASP – Top Ten Vulnerabilities
    16. 16. A1.Injection
    17. 17. What is a SQL Injection?• A SQL injection attack consists of insertion or "injection" of a SQL query via the inputdata from the client to the application.• Any user-controlled parameter that gets processed by the application might be hidingvulnerability.This includes: Application parameters in query strings (e.g., GET requests) Application parameters included as part of the body of a POST request Browser-related information (e.g., user-agent, referrer) Host-related information (e.g., host name, IP) Session-related information (e.g., user ID, cookies)
    18. 18. What is a SQL Injection?• Classes of SQL injection Inband: data is extracted using the same channel that is used toinject the SQL code. This is the most straightforward kind ofattack, in which the retrieved data is presented directly in theapplication web page. Out-of-band: data is retrieved using a different channel (e.g., anemail with the results of the query is generated and sent to thetester). Inferential: there is no actual transfer of data, but the tester isable to reconstruct the information by sending particular requestsand observing the resulting behavior of the DB Server.
    19. 19. Type of tests that can be conductedThe tester has to:make a list of all input fields whose values could be used in crafting aSQL query, including the hidden fields of POST requests and then testthem separately try to interfere with the query and to generate an error. He can add asingle quote (‘) , (;), comments (--) or SQL keywords like ‘AND’ or ‘OR’.Example of error message that gives to the attacker very useful information:Microsoft OLE DB Provider for ODBC Drivers error 80040e14[Microsoft][ODBC SQL Server Driver][SQL Server]Unclosed quotation mark before thecharacter string ./target/target.asp, line 113
    20. 20. Type of tests that can be conductedStandard SQL InjectionUnion Query SQL InjectionBlind SQL InjectionStore Procedure Injection
    21. 21. SQL Injection – Illustrated Get AccountsFirewallHardened OSWeb ServerApp ServerFirewallDatabasesLegacySystemsWebServicesDirectoriesHumanResrcsBillingCustom CodeAPPLICATIONATTACKNetworkLayerApplicationLayerAccountsFinanceAdministrationTransactionsCommunicationKnowledgeMgmtE-CommerceBus.FunctionsHTTPrequestSQLqueryDB TableHTTPresponse"SELECT * FROMaccounts WHEREacct=‘’ OR1=1--’"1. Application presents a form tothe attacker2. Attacker sends an attack inthe form data3. Application forwards attack tothe database in a SQL queryAccount SummaryAcct:5424-6066-2134-4334Acct:4128-7574-3921-0192Acct:5424-9383-2039-4029Acct:4128-0004-1234-02934. Database runs querycontaining attack and sendsencrypted results back toapplication5. Application decrypts data asnormal and sends results to theuserAccount:SKU:Account:SKU:
    22. 22. SQL Injection – Illustrated Login FormSELECT * FROM `Login` WHERE `User`=‘John’ AND`Pass`=‘John@123’Login Database TableJohn********John@123JohnUser PassJohn John@123
    23. 23. SQL Injection – Illustrated get accessSELECT * FROM `Login` WHERE `User`=‘’ OR ‘a’=‘a’AND `Pass`=‘’ OR ‘a’=‘a’Always TRUE!!!’ OR ‘a’=‘a*********’ OR ‘a’=‘a’ OR ‘a’=‘a
    24. 24. SQL Injection – Illustrated drop the tableSELECT * FROM `Login` WHERE `User`=‘’ ’; DROP TABLE `login`; -- ’AND `Pass`=‘’If database is not Readonly!’; DROP TABLE `login`; --’; DROP TABLE `login`; --
    25. 25. ToolsWebScarabZAPSqlDumperSQLixSQLninjaSQLinjector
    26. 26. Prevention of SQL Injection•Applications have to:validate and to sanitize all user inputnever use dynamic SQLexecute using an account with few privilegeshash or encrypt their secretspresent error messages that reveal little if nouseful information to the hacker
    27. 27. References• https://www.owasp.org/index.php/SQL_Injection• http://www.websec.ca/kb/sql_injection• http://www.securesolutions.no/why-its-easy-being-a-hacker/• http://pentestmonkey.net/cheat-sheet/sql-injection/oracle-sql-injection-cheat-sheet• http://www.integrigy.com/files/Integrigy_Oracle_SQL_Injection_Attacks.pdf• http://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet• http://unixwiz.net/techtips/sql-injection.html
    28. 28. End of part one
    29. 29. A2.Cross-Site Scripting (XSS)
    30. 30. Cross-Site Scripting IllustratedApplication withstored XSSvulnerability32Attacker sets the trap – update my profileAttacker enters amalicious script into aweb page that storesthe data on the server1Victim views page – sees attacker profileScript silently sends attacker Victim’s session cookieScript runs insidevictim’s browser withfull access to the DOMand cookiesCustom CodeAccountsFinanceAdministrationTransactionsCommunicationKnowledgeMgmtE-CommerceBus.Functions
    31. 31. Simple XSS Attackhttp://myserver.com/test.jsp?name=Stefanhttp://myserver.com/welcome.jsp?name=<script>alert("Attacked")</script><HTML><Body>Welcome Stefan</Body></HTML><HTML><Body>Welcome<script>alert("Attacked")</script></Body></HTML>
    32. 32. XSS-Attack: Another examplePost Forum Message:Subject: GET Money for FREE !!!Body:<script> attack code </script>1. Attacker sends malicious code2. Server stores messageDid you know this?.....3. User requests message4. Message is delivered by server5. Browser executes script in messageGET Money for FREE !!!<script> attack code </script>Get /forum.jsp?fid=122&mid=2241AttackerClientWeb ServerGET Money for FREE !!!<script> attack code </script>!!! attack code !!!Re: Error message on startup.....I found a solution!.....Can anybody help?.....Error message on startup.....
    33. 33. XSS Attacks• Sun Microsystemss Java• Client-side Script• JavaScript• Action Script• VB Script• Microsoft’s Active X• Adobe’s Flash• HTML or XHTML• RSS and Atom feedsProgramming Languages Usedin XSS AttacksXSS Attacks Used For:• Hijacking Accounts• False Advertising & insertinghostile content• Cookie theft/poisoning &defacing websites• Changing of users settings• Conducting phishing attacks
    34. 34. Prevention of XSS Attack• Input Validation Check if the input is what you expect Do not try to check for "bad input" Black list testing is no solution Black lists are never complete! White list testing is better Only what you expect will pass Regular expressions• HTML Encoding HTML encoding of all input when put into output pages• Cookie Options mitigate the impact "httpOnly" Cookies "secure" Cookies. Cookies are only sent over SSL
    35. 35. References• http://www.owasp.org/index.php/XSS_(Cross Site Scripting) PreventionCheat Sheet• http://ha.ckers.org/xss.html
    36. 36. A3.Broken Authentication and Session Management
    37. 37. Broken Authentication IllustratedCustom CodeAccountsFinanceAdministrationTransactionsCommunicationKnowledgeMgmtE-CommerceBus.Functions1 User sends credentials2Site uses URL rewriting(i.e., put session in URL)3 User clicks on a link tohttp://www.hacker.com in a forumwww.boi.com?JSESSIONID=9FA1DB9EA...4Hacker checks referer logs onwww.hacker.comand finds user’s JSESSIONID5Hacker uses JSESSIONIDand takes over victim’saccount
    38. 38. Avoiding Broken Authentication and SessionManagement• Verify your architecture Authentication should be simple, centralized, and standardized Use the standard session id provided by your container Be sure SSL protects both credentials and session id at all times• Verify the implementation Forget automated analysis approaches Check your SSL certificate Examine all the authentication-related functions Verify that logoff actually destroys the session• Follow the guidance from http://www.owasp.org/index.php/Authentication_Cheat_Sheet
    39. 39. A4.Insecure Direct Object References
    40. 40. Insecure Direct Object References Illustrated• Attacker notices hisacct parameter is6065 ?acct=6065• He modifies it to anearby number?acct=6066• Attacker views thevictim’s accountinformationhttps://www.onlinebank.com/user?acct=6065https://www.onlinebank.com/user?acct=6066
    41. 41. Avoiding Insecure Direct Object References• Eliminate the direct object reference Replace them with a temporary mapping value (e.g. 1, 2, 3) ESAPI provides support for numeric & random mappings• IntegerAccessReferenceMap & RandomAccessReferenceMap• Validate the direct object reference Verify the parameter value is properly formatted Verify the user is allowed to access the target object• Query constraints work great!• Verify the requested mode of access is allowed to the target object (e.g.,read, write, delete)http://app?file=1Report123.xlshttp://app?id=7d3J93Acct:9182374http://app?id=9182374http://app?file=Report123.xls
    42. 42. A5.Cross Site Request Forgery (CSRF)
    43. 43. Cross Site Request Forgery (CSRF)• Occurs when an authenticated user unknowingly initiates a request• The request is handled as if it were intentionalUsually happens without the user being aware!• CSRF attacks are difficult to trackCommands are executed in the context of the victimThe request comes from the users IP address so it is difficult to hunt down thehacker• The hacker is essentially given all of the user’s privileges
    44. 44. CSRF Vulnerability Pattern• The Problem Web browsers automatically include most credentials with each request Even for requests caused by a form, script, or image on another site• All sites relying solely on automatic credentials are vulnerable! (almost all sites are this way)• Automatically Provided Credentials Session cookie Basic authentication header IP address Client side SSL certificates Windows domain authentication
    45. 45. Prevention of CSRF• Add a secondary authentication mechanism (e.g., as an impossible toguess token)• Require a confirmation page before executing potentially dangerousactions• Eliminate XSS vulnerabilities• Use POST as your form action and only accept POST requests onthe server for sensitive data !• Incoming CSRF requests will fail since the parameter is in the URLand not the post body• You can protect yourself with RequestPolicy (Firefox extension)References:– www.owasp.org/index.php/CSRF_Prevention_Cheat_Sheet
    46. 46. A6.Security Misconfiguration
    47. 47. Hardened OSWeb ServerApp ServerFrameworkSecurity Misconfiguration IllustratedApp ConfigurationCustom CodeAccountsFinanceAdministrationTransactionsCommunicationKnowledgeMgmtE-CommerceBus.FunctionsTest ServersQA ServersSource ControlDevelopmentDatabaseInsider
    48. 48. Security Misconfiguration. Attack scenarios• Scenario #1: Your application relies on a powerful frameworklike Struts, Spring or MVC. XSS flaws are found in theseframework components you rely on. An update is released tofix these flaws but you don’t update your libraries. Until you do,attackers can easily find and exploit these flaw in your app.• Scenario #2: The app server admin console is automaticallyinstalled and not removed. Default accounts aren’t changed.Attacker discovers the standard admin pages are on yourserver, logs in with default passwords, and takes over.• Scenario #3: App server configuration allows stack traces tobe returned to users, potentially exposing underlying flaws.Attackers love the extra information error messages provide.
    49. 49. Prevention Security Misconfiguration• Verify your system’s configuration management Secure configuration “hardening” guideline Automation is REALLY USEFUL here Must cover entire platform and application Keep up with patches for ALL components This includes software libraries, not just OS and Server applications Analyze security effects of changes• Can you “dump” the application configuration Build reporting into your process If you can’t verify it, it isn’t secure• Verify the implementation Scanning finds generic configuration and missing patch problems
    50. 50. A7.Failure to Restrict URL Access
    51. 51. Failure to Restrict URL Access Illustrated• Attacker notices theURL indicates hisrole/user/getAccounts• He modifies it toanother directory(role)/admin/getAccounts,or/manager/getAccounts• Attacker views moreaccounts than justtheir ownhttps://www.onlinebank.com/user/getAccountshttps://www.onlinebank.com/admin/getAccounts
    52. 52. Avoiding URL Access ControlFlaws• For each URL, a site needs to do 3 things Restrict access to authenticated users (if not public) Enforce any user or role based permissions (if private) Completely disallow requests to unauthorized page types (e.g., config files,log files, source files, etc.)• Verify your architecture Use a simple, positive model at every layer Be sure you actually have a mechanism at every layer• Verify the implementation Verify that each URL in your application is protected by either Verify the server configuration disallows requests to unauthorized file types Use WebScarab or your browser to forge unauthorized requests
    53. 53. A8.Insecure Cryptographic Storage
    54. 54. Insecure Cryptographic Storage IllustratedCustom CodeAccountsFinanceAdministrationTransactionsCommunicationKnowledgeMgmtE-CommerceBus.Functions1Victim enters creditcard number in form2Error handler logs CCdetails becausemerchant gateway isunavailable4 Malicious insidersteals 4 millioncredit cardnumbersLog files3Logs are accessible toall members of IT stafffor debugging purposes
    55. 55. Insecure Cryptographic Storage Prevention• Verify your architecture Identify all sensitive data Identify all the places that data is stored Ensure threat model accounts for possible attacks Use encryption to counter the threats, don’t just ‘encrypt’ the data• Protect with appropriate mechanisms File encryption, database encryption, data element encryption• Use the mechanisms correctly Use standard strong algorithms Generate, distribute, and protect keys properly Be prepared for key change• Verify the implementation A standard strong algorithm is used, and it’s the proper algorithm for this situation All keys, certificates, and passwords are properly stored and protected Safe key distribution and an effective plan for key change are in place Analyze encryption code for common flaws
    56. 56. A9. Insufficient Transport Layer Protection
    57. 57. Insufficient Transport Layer Protection IllustratedCustom CodeEmployeesBusiness PartnersExternal VictimBackend SystemsExternal Attacker1Externalattacker stealscredentials anddata offnetwork2Internal attackersteals credentialsand data frominternal networkInternal Attacker
    58. 58. Avoiding Insufficient Transport Layer Protection• Protect with appropriate mechanisms Use TLS on all connections with sensitive data Individually encrypt messages before transmission E.g., XML-Encryption Sign messages before transmission E.g., XML-Signature• Use the mechanisms correctly Use standard strong algorithms (disable old SSL algorithms) Manage keys/certificates properly Verify SSL certificates before using them Use proven mechanisms when sufficient E.g., SSL vs. XML-EncryptionReferences:• http://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet
    59. 59. A10.Unvalidated Redirects and Forwards
    60. 60. Unvalidated Redirect Illustrated32Attacker sends attack to victim via email orwebpageFrom: Internal Revenue ServiceSubject: Your Unclaimed TaxRefundOur records show you have anunclaimed federal tax refund.Please click here to initiate yourclaim.1Request sent tovulnerable site, includingattacker’s destination siteas parameter. Redirectsends victim to attackersiteCustom CodeAccountsFinanceAdministrationTransactionsCommunicationKnowledgeMgmtE-CommerceBus.Functions4Victim clicks link containing unvalidatedparameterEvil Sitehttp://www.irs.gov/taxrefund/claim.jsp?year=2006& … &dest=www.evilsite.com
    61. 61. Unvalidated Forward Illustrated2Attacker sends attack to vulnerable page they haveaccess to1Application authorizesrequest, whichcontinues tovulnerable pageRequest sent tovulnerable page whichuser does have accessto. Redirect sends userdirectly to privatepage, bypassingaccess control.3 Forwarding page fails to validateparameter, sending attacker tounauthorized page, bypassingaccess controlpublic void doPost( HttpServletRequest request,HttpServletResponse response) {try {String target = request.getParameter( "dest" ) );...request.getRequestDispatcher( target ).forward(request, response);}catch ( ...Filterpublic voidsensitiveMethod( HttpServletRequestrequest, HttpServletResponseresponse) {try {// Do sensitive stuff here....}catch ( ...
    62. 62. Unvalidated Redirects and Forwards Prevention Avoid using redirects and forwards as much as you can If used, don’t involve user parameters in defining the targetURL Validate each parameter to ensure its valid and authorized forthe current user Use server side mapping to translate choice provided to userwith actual target page (preferred) Defense in depth: For redirects, validate the target URL after itis calculated to make sure it goes to an authorized external site
    63. 63. OWASP Enterprise Security APIESAPI Homepage: http://www.owasp.org/index.php/ESAPI
    64. 64. It all ends here…Security Testing isperformed.Security considerations areintroducedin development process&Unless…
    65. 65. Q&A
    66. 66. Thank you!Stefana Botezatu

    ×