Your SlideShare is downloading. ×
  • Like
  • Save
Security testing
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Now you can save presentations on your phone or tablet

Available for both IPhone and Android

Text the download link to your phone

Standard text messaging rates apply
Published

 

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
2,805
On SlideShare
0
From Embeds
0
Number of Embeds
2

Actions

Shares
Downloads
0
Comments
0
Likes
1

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    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

Transcript

  • 1. Security TestingStefana BotezatuMay, 2013
  • 2. Security Testing•Generalities•OWASP - Top Ten Vulnerabilities
  • 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. All begin from here …
  • 5. What can cause trouble?
  • 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. 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. 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. 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. 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. 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. 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. Security Testing Techniques• Manual Inspections & Reviews• Threat Modeling• Balanced Approach
  • 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. OWASP – Top Ten Vulnerabilities
  • 16. A1.Injection
  • 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. 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. 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. Type of tests that can be conductedStandard SQL InjectionUnion Query SQL InjectionBlind SQL InjectionStore Procedure Injection
  • 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. SQL Injection – Illustrated Login FormSELECT * FROM `Login` WHERE `User`=‘John’ AND`Pass`=‘John@123’Login Database TableJohn********John@123JohnUser PassJohn John@123
  • 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. 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. ToolsWebScarabZAPSqlDumperSQLixSQLninjaSQLinjector
  • 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. 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. End of part one
  • 29. A2.Cross-Site Scripting (XSS)
  • 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. 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. 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. 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. 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. References• http://www.owasp.org/index.php/XSS_(Cross Site Scripting) PreventionCheat Sheet• http://ha.ckers.org/xss.html
  • 36. A3.Broken Authentication and Session Management
  • 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. 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. A4.Insecure Direct Object References
  • 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. 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. A5.Cross Site Request Forgery (CSRF)
  • 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. 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. 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. A6.Security Misconfiguration
  • 47. Hardened OSWeb ServerApp ServerFrameworkSecurity Misconfiguration IllustratedApp ConfigurationCustom CodeAccountsFinanceAdministrationTransactionsCommunicationKnowledgeMgmtE-CommerceBus.FunctionsTest ServersQA ServersSource ControlDevelopmentDatabaseInsider
  • 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. 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. A7.Failure to Restrict URL Access
  • 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. 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. A8.Insecure Cryptographic Storage
  • 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. 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. A9. Insufficient Transport Layer Protection
  • 57. Insufficient Transport Layer Protection IllustratedCustom CodeEmployeesBusiness PartnersExternal VictimBackend SystemsExternal Attacker1Externalattacker stealscredentials anddata offnetwork2Internal attackersteals credentialsand data frominternal networkInternal Attacker
  • 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. A10.Unvalidated Redirects and Forwards
  • 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. 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. 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. OWASP Enterprise Security APIESAPI Homepage: http://www.owasp.org/index.php/ESAPI
  • 64. It all ends here…Security Testing isperformed.Security considerations areintroducedin development process&Unless…
  • 65. Q&A
  • 66. Thank you!Stefana Botezatu