1 / 42

Secure Software

Secure Software Professional Recommendations from CWE/SANS References Material is from:: 2009 CWE/SANS Top 25 Most Dangerous Programming Errors, Version 1.4, Oct 29, 2009. Author: Susan J Lincke, PhD Univ. of Wisconsin-Parkside Reviewers/Contributors: Todd Burri

omer
Télécharger la présentation

Secure Software

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Secure Software Professional Recommendations from CWE/SANS

  2. References Material is from:: • 2009 CWE/SANS Top 25 Most Dangerous Programming Errors, Version 1.4, Oct 29, 2009. Author: • Susan J Lincke, PhD Univ. of Wisconsin-Parkside Reviewers/Contributors: Todd Burri Funded by National Science Foundation (NSF) Course, Curriculum and Laboratory Improvement (CCLI) grant 0837574: Information Security: Audit, Case Study, and Service Learning. Any opinions, findings, and conclusions or recommendations expressed in this material are those of the author(s) and/or source(s) and do not necessarily reflect the views of the National Science Foundation.

  3. Problem: Incorrect Input Car Sale Model: Chevrolet XR2 Price $: 25.45 VIN: 12K4FG436DDE842 Status: New Sale to: Rubber Ducky 2222 Atlantic Ocean Antarctica, NY, 00000 Phone: 911 VISA: RUAFOOL444

  4. Problem: Buffer overflow Enter Name: Zzzzzzzzzzzzzz zzzzzzzzzzzzzzzzzzzzzzzzzz zzzzzzzzzzzzzzzzzzzzzzzzz zzzzzzzzzzzzzzzzzzzz

  5. Fix: Input Validation Assume all input is malicious! Validate: • Length • Type • Syntax • Context: Business Rules Or Use • Special input checkers • Struts or OWASP ESAPI Validation API • Whitelist: List of acceptable input • Blacklist: Reject suspect input Validate First!!! network

  6. Problem: Insecure Interaction Between Components real -> network Program B Attack: Code is reverse engineered and modified to act differently. fake -> Problem: Server assumes validation occurred in client Does not recheck Program B*

  7. Fix:Server-Side Authentication real -> network • Perform authentication and input validation on both client and server sides • Use encryption & hash between client & server

  8. Problem:SQL Injection • Java Original: “SELECT * FROM users_table WHERE username=” + “’” + username + “’” + “ AND password = “ + “’” + password + “’”; • Inserted Password: Aa’ OR ‘’=’ • Java Result: “SELECT * FROM users_table WHERE username=’anyname’ AND password = ‘Aa’ OR ‘ ‘ = ‘ ‘; • Inserted Password: foo’;DELETE FROM users_table WHERE username LIKE ‘% • Java Result: “SELECT * FROM users_table WHERE username=’anyname’ AND password = ‘foo’; DELETE FROM users_table WHERE username LIKE ‘%’ Login: Password: Welcome to My System

  9. Fix: Input Sanitization • Avoid dynamically-constructed query strings • Disallow Meta-characters Persistence Software: • Oracle DBMS_ASSERT • MySQL mysql_real_escape_string() for C, PHP • Hibernate or Enterprise Java Beans if used properly GUI - Validation Business Logic Persistence Layer Database

  10. Problem: OS Command Injection Problem: Command Injection into SQL • Inserts ‘|shell(“cmd /c echo “ & char(124) & “format c:”)|’ • Data and control can traverse same path Login: Password: Welcome to My System

  11. Fix: Avoid OS Command Injection • Separate control information from data information. • E.g. where data-> database, control defines application • Use library calls instead of external processes • Avoid external control of command input • Run code in “jail” or other sandbox environment • Provide lowest possible permissions for executable Data: “Terry, Brian, Jerry, Ann, Louis, …” Control: Start WPI session, parms -lmk

  12. User-side data can be modified: Cookies Configuration files Profiles Hidden form fields Environmental variables Registry keys Problem:External Control of Critical State Data Web request Web Form Form with fake data

  13. Fix:Control Critical State Data • Understand all locations that are accessible to attackers • Do not keep state info on client without using encryption and integrity checking (e.g. HMAC) • Store state info on server side only: ASP.NET View State, OWASP ESAPI Session Mgmt

  14. Web servers are memoryless Do not remember sending a form to a client – what type, info Client side can remove checks, insert other code, return unexpected data, etc. Problem:Insecure Interaction Between Components Web access Web Form with javascript Revised form With data and java script

  15. Problem:Cross-Site Scripting A reputable site has links to an unknowingly disreputable site The disreputable site generates a Javascript or VB script, which gets inserted into the reputable company’s html response. The result looks like a valid web page from the reputable company. E.g.: Error: Page not found Web access to product link reference Should be error (Not Found) Instead: fake form Web Form with javascript attack

  16. Fix:Preserve Web Page Structure • Specify strong character encoding such as UTF-8 or ISO-8859. • Use on output • Check on input • Or use other encoders: MS Anti-XSS library, OWASP ESAPI Encoding, Apache Wicket • Validate not only input data, but all parts of the HTTP input.

  17. Problem:Forgery Web access Web Form with javascript Fake form With data and java script Real form Also known as Cross-Site Request Forgery

  18. Problem:Improper Access Control Web access Web Form need authentication Reply to www.abc.com/123 Web Reply w. authent. To www.abc.com/123 cache Web Form for actual data for www.abc.com/345 Web Request for www.abc.com/345 Web Form for actual data for www.abc.com/345

  19. Fix:Access Permissions • Use Role-Based Access • At least permissions: anonymous, normal, privileged, administrative • Verify access control at server side • Sensitive pages are never cached and must have active authorization token • Only provide higher level access when you need it; always run with the minimum possible authorization level • Check that files read have the required access level permissions; administrators may not set them properly. • Use a good random number generator when generating random session keys – if not random, attackers will figure out next key sequence

  20. Problem:Incorrect Access Permissions What permissions to use for these forms???

  21. Use a nonce for each form Not predictable If dangerous operation, send a separate confirmation request Fix:Prevent Forgery Name: Ann Winkler Address: 2526 Pratt Ave Racine WI Phone: 262-595-2111 Interests: Horses, Movies, Travel Security Code: Johnson Rivers Security Code: Johnson Rivers Submit

  22. Problem:Cleartext Transmit of Sensitive Info Login: Ginger Password: Snap Fix: • Encrypt data with standard, reliable encryption before transmission

  23. Problem:Race Condition Thread P1 Thread P2 Comment cin >> input; .. // read in "hello" into global .. cin >> input; // read in "good-bye" into global out = input; out = input; // do a string copy (...use strcpy()) cout << out; .. // print out "good-bye" .. cout << out; // print out "good-bye“ Fix: • Use Synchronization Primitives around critical code • Minimize use of shared resources • Test using artificial delays in race window • Identify and trigger error conditions Result: Data Corruption & Denial of Service

  24. “Cannot find file: C:/users/Lincke/validation.txt” “Invalid password for login ID” “Lab.cs.uwp.edu error: divide by zero error” Fix: Error messages should avoid file, network configuration, and PII information. Must be helpful to user Remove debug info before release Problem:Chatty Error Messages

  25. Problem:External Control of Path • If you download an external file or navigate to a URL – and execute • If you provide access to a file on your system • Attacker can insert ../../ and access files outside privilege. Fix: • Run as low-privilege user • Provide fixed input values • Run code in ‘jail’: Unix chroot jail and AppArmor Submit File: Enter pathname: Browse Browse

  26. Fix: Use monitoring tools that examine processes as it interacts with the OS Truss (Solaris) Strace (Linux) FileMon, RegMon, Process Monitor, Sysinternals (Windows) Sniffers, Protocol analyzers Problem:Adopting Untrusted Software Download File Free Software … Is it Safe?

  27. Problem:Other Security Errors Find the errors: Security() { String contents, environment; String spath = “security.dat” File security = new File; if (security.open(“spath”) >0) contents = security.read(); environment = security.read(); else print(“Error: Security.dat not found”); }

  28. Find the errors: Security() { String contents, environment; String spath = “security.dat” File security = new File; if (security.open(“spath”) >0) contents = security.read(); environment = security.read(); else print(“Error: Security.dat not found”); } Variables contents & environment not initialized Can cause problems if executed in certain ways Attacker can initialize or read variables from previous session “security.dat” is not full pathname. File can be replaced if run from another location File ‘security’ not closed Leaves file open to attack Keeps unnecessary resources busy Error message indicates file name Can give attacker important info Problem:Other Security Errors

  29. Problem:More Security Errors Find the errors: purchaseProduct() { password = “N23m**2d3”; count = form.quantity; total = count * product.cost(); Message m = new Message( name,product,total); m.myEncrypt(); server.send(m); }

  30. Find the errors: purchaseProduct() { password = “N23m**2d3”; count = form.quantity; total = count * product.cost(); Message m = new Message( name,password,product,total); m.myEncrypt(); server.send(m); } Errors: Password is hardcoded If attacker finds it, every system can be broken into before software is changed on all computers Passwords may only be stored in encrypted file Total may overflow, producing very small number Input is not checked (could be zero or invalid) Encryption should be standard algorithm Home-written variety can be broken into easily Problem:More Security Errors

  31. Fix: Test All Software!!! • Dynamic Tools: use large test suites such as fuzz testing, robustness testing, and fault injection. Software may slow down but should not crash or generate incorrect results • Use automated static analysis tools, e.g., warnings on program analysis tools • Use manual tests such as penetration testing, threat modeling, and interactive tools to reach beyond auto testing tools • Run program under low memory conditions, insufficient privileges, interrupt a transaction or disable connectivity before transaction completed.

  32. Question A third party inserts attack data into another organization’s html response. This is known as: • Cross-Site Scripting • Blacklist • Race Condition • Cleartext

  33. Question What technique would NOT be appropriate in avoiding OS Command Injection? • Separate control information from data information • Use library calls instead of external processes • Run code in “jail” or other sandbox environment • Use a hard-coded password to enable access

  34. Question Which of the following is true concerning web servers? • Servers cannot retain web session state, and thus the client must do it • The single best place to do input validation and authentication is at the client-side • Using client as storage is safe if encryption and integrity checking are used • The server can trust web input if it validates the data in the web form

  35. Question The BEST way to ensure input validity at the client is: • Nonce • Whitelist • Blacklist • Integrity Checking

  36. Question The BEST implementation of Access Control would be: • Do not provide caches for sensitive data • Always use minimal possible permissions in code, for as short of a time as possible • Avoid using cookies and hidden fields • Never provide an authorization above ‘guest’ to web users

  37. Question SQL Injection is BEST protected against by using: • Cleartext • Encryption and Integrity Checking • Sanitization • Clearly defined code such as UTF-8

  38. Question The main way to avoid replay between a client and server is: • Integrity checking • Whitelist • Blacklist • Nonce

  39. Question An attack that could cause the MOST problems includes: • Hard-coded password • Race condition • Denial of Service • Chatty error message

  40. Question The BEST way to ensure no message modification occurs is: • Hashing • Whitelist • Blacklist • Encryption

  41. Question All of the following EXCEPT which answer can result in invalid data AND break-in? • Non-random random number generator • Buffer overflow • Uninitialized variables resulting in error messages • Race conditions

  42. Vocabulary Buffer overflow, SQL injection, OS command injection, cross-site scripting, cleartext, race condition, chatty error message Sanitization, whitelist, blacklist, nonce, character encoding (UTF-8), jail or sandbox environment

More Related