1. CSCE 548 Secure Software Development Web Application Security

2. Reading 19/24 Deadly sins of software security: – Web Server Related Vulnerabilities – Web Client Related Vulnerabilities Recommended: – R. Rosenbaum, Richard Clarke on Who Was Behind the Stuxnet Attack, Smithsonian, April 2012, http://www.smithsonianmag.com/history-archaeology/Richard- Clarke-on-Who-Was-Behind-the-Stuxnet-Attack.html http://www.smithsonianmag.com/history-archaeology/Richard- Clarke-on-Who-Was-Behind-the-Stuxnet-Attack.html – N. Antunes, M. Vierira, The Devils Behind Web Application Vulnerabilities, IEEE Computer, Febr. 2012, http://www.uc.pt/en/fctuc/dei/ensino/doctoral_program/nunoantun es http://www.uc.pt/en/fctuc/dei/ensino/doctoral_program/nunoantun es CSCE 548 - Farkas2

3. Survey Request Smart Phone Apps Security project – Conducting a survey to get an understanding of how most users currently use security software and features with their phone – Results from the survey will be used to find common usage features and create a best practices guide link to survey: https://docs.google.com/spreadsheet/viewform?formkey=dHNiRDlP Q2U2SjlOektubnZVUXYyelE6MQ CSCE 548 - Farkas3

4. 4 Web Application Security Concerns What do we want to protect? CSCE 548 - Farkas

5. 5 Security Layers Security Layers 1. Data- and metadata-level security 2. Software-level (application) security 3. Business-level security 4. National security Security Technologies, authentication, secure communication, policies, etc. CSCE 548 - Farkas

6. Web Data and Metadata Security Structured data, XML, …, html, unstructured data ER model,RDF, …, OWL Workflow, BPEL, WSBPEL, … 6CSCE 548 - Farkas

7. Secure XML Views - Example UC S John Smith UC 111-2222 S Jim Dale UC TS S Harry Green UC 333-4444 S Joe White UC MT78 TS medicalFiles countyRec patient name John Smith milBaseRec physician Jim Dale physician Joe White name Harry Green milTag MT78 patient phone 111-2222 phone 333-4444 View over UC data CSCE 548 - Farkas

8. Transformation - Example MPG TS S UC SP medicalFiles emergencyRec name physician Data Structure

9. Delete - Example Report Title Data Date Temperature Images Water Resources Concrete Location Civil Area Defense Sector P P P P P S S S S TS ?

10. Report Title Data Date Temperature Images Concrete Location Defense Sector (S,{Del}) TS P P P P P Example - Top Secret View Subject clearances: (TS, {})  { (TS, {}), (S, {Del}), (P, {Del}) } (S, {})  { (S, {}), (P, {Del}) } (P, {})  { (P, {}) }

11. Node Association - Example DTD of Patient Health Record MedicalDb Patient * Allergies Allergen * Phone Birthdate Name SSN Race DateDiagnosis Physician Prescription * Comments Patient Phone Name Patient Birthdate Race DateDiagnosis Comments

12. Simple Security Object t1t1 t4t4 t3t3 t2t2 o  t i : (t i ) = (o)

13. t1t1 t4t4 t3t3 t2t2 o  t i : (t i ) < (o) Association Security Object

14. The Inference Problem General Purpose Database: Non-confidential data + Metadata  Undesired Inferences Semantic Web: Non-confidential data + Metadata (data and application semantics) + Computational Power + Connectivity  Undesired Inferences

15. Correlated Inference Object[]. waterSource :: Object basin :: waterSource place :: Object district :: place address :: place base :: Object fort :: base address fort Public Water source base Confidential district basin Public ? Concept Generalization: weighted concepts, concept abstraction level, range of allowed abstractions

16. Correlated Inference (cont.) address fort Public district basin Public Object[]. waterSource :: Object basin :: waterSource place :: Object district :: place address :: place base :: Object fort :: base place base Water Source Water source Base Place Water source base Confidential

17. 17 Software Security CSCE 548 - Farkas

18. 18 Web Applications Aggregated services  each component is vulnerable What is the level of security provided by the aggregate? –Trust management Security Patterns –Exception Shielding –Message Screening –Trusted subsystem –Service Perimeter Guard CSCE 548 - Farkas

19. 19 Exception Shielding Goal Goal: prevent the disclosure of information about the service’s internal implementation via exception data Problem Problem: – Exception data released by a service may contain internal implementation details – Malicious users may exploit this data to compromise the service and its environment Solution Solution: replace unsafe data with data that is safe by design CSCE 548 - Farkas

20. 20 Improper Error Handling OWASP “A7 Improper Error handling,” 2007, http://cwe.mitre.org/data/definitions/728.html http://cwe.mitre.org/data/definitions/728.html Variants: – Yielding too much information – Ignoring errors – Misinterpreting errors – Using useless error values – Handling the wrong exception – Handling all exceptions together CSCE 548 - Farkas

21. 21 Sanitization Process Customer Server Customer submits a request message Server: attempts to process The request and throws an Exception Exception Shielding Routines: Evaluates exception data and Replaces it if unsafe Server returns safe exception message CSCE 548 - Farkas

22. 22 Message Screening Goal Goal: protect a service from malformed or malicious input Problem Problem: – Malicious user may violate service security or take over the control of the service and its environment Solution Solution: assume all input data is harmful and screen before using it CSCE 548 - Farkas

23. 23 Input Validation OWASP: CWE-20: improper Input Validation, http://cwe.mitre.org/data/definitions/20.html http://cwe.mitre.org/data/definitions/20.html Problem Problem: no or improper validation of input that can affect control flow or data flow of a program Variants Variants: – Buffer overrun – Integer overflow – Command injection – SQL injection Reading: G. Hoglund and G. McDraw, Exploiting Software: How to Break Code, Chapter 7 Buffer Overflow, http://searchsecurity.techtarget.com/searchSecurity/downlo ads/Exploiting Software-Ch07.pdf http://searchsecurity.techtarget.com/searchSecurity/downlo ads/Exploiting Software-Ch07.pdf CSCE 548 - Farkas

24. 24 Trusted Subsystem Goal Goal: prevent customers from circumventing a service and directly accessing the resources of the service Problem Problem: – Customer may perform incorrect modifications – May lead to undesirable forms of implementation coupling Solution Solution: service is designed to use own credentials for authentication with backend resources CSCE 548 - Farkas

25. 25 Impact Compromised service Compromised service may allow access to unauthorized users Protocol for accessing remote resources Protocol for accessing remote resources 1. Authenticate and authorize the message 2. Send a request to the remote resource, accompanied with the services’ own credentials 3. Issue the appropriate issue to the customer CSCE 548 - Farkas

26. 26 Implementation Variants Service accounts within the trusted subsystem Local accounts are used on each host Use digital certificate (e.g., X509 PKI) for authentication in the trusted subsystem Use IPSec to provide secure communications. CSCE 548 - Farkas

27. 27 Perimeter Guard Goal Goal: protect internal resources from users that remotely access internal computers Problem Problem: – External attacker may gain access to services running within a private network, and thus to the resources within the private network Solution Solution: establish an intermediate service at the perimeter of the private network as a secure contact point CSCE 548 - Farkas

28. 28 Network-Level Security Messaging middleware – Communication security – End point security Protocol assurance Authentication and identification Cross-domain communication security CSCE 548 - Farkas

29. 29 Service-Level Security Ongoing research: – Business process execution across heterogeneous domains – Identity management – Trust management Upcoming research areas: – Web Services Composition – Web Service Transactions – Service-Level Dependencies CSCE 548 - Farkas

30. 30 Web Services Composition Create complex applications on the fly from individual services BPEL4WS, WSBPEL How to express security and reliability needs? How to verify that these needs are satisfied? How to resolve conflict between business needs and security requirements? CSCE 548 - Farkas

31. 31 Web Services Transactions Traditional database transaction managements vs. SOA application needs How can we evaluate correct execution? ACID properties? Serializability? WS transaction framework: – Atomic (short-term) transactions – Business activity (long-term) transactions What are the security implications of WS transactions? CSCE 548 - Farkas

32. 32 Service-Level Dependencies Old threats reappearing in new context: deadlocks, denial- of-service, network flooding, etc. How to detect and prevent the occurrence of these threats? In composition, independently developed services are dependent on each other No information about internal processing of the workflow components CSCE 548 - Farkas

33. Web Technologies and Security CSCE 548 - Farkas33

34. Topics and Concepts Threats unique to web applications Forgery for web application input Management of web-specific languages Cross-site scripting and cross-site forgery request Rules for web-based system input Management of file uploads and system access CSCE 548 - Farkas34

35. @ Hidden symbol in URL Change IP address (only the info to the right of @ is used) Browser vulnerability – “You are about to log in to the site “cse.sc.edu” with the username “farkas”, but the website does not require authentication. This may be an attempt to trick you.” Twitter – executable JavaScript after @ CSCE 548 - Farkas35

36. Who is at risk? Client: browsers – Complex systems – Plug-ins, extensions – Server authentication JavaScript and paid ads  ease of propagating malicious code Never trust a client on the server side Never trust a browser on the client side CSCE 548 - Farkas36

37. Improve client security Install patches to the browser Update commonly used plug-ins Eliminate unused plug-ins Heed your browser warnings Make antivirus software watch browser and downloads Clear history, stored files, and cookies If a file is not signed and trusted, don’t download it CSCE 548 - Farkas37

38. Improve server side security Never execute client input as code Never allow client input to pass into the system without validating it internally Scrub client input for any known exploits and suspect characters Keep a layer of indirection between client input received and the system Manage sessions from inside the trust boundary and not on the client side Never encode secrets of functional variables in information sent to the clies. CSCE 548 - Farkas38

39. Biggest Threats to Web Applications Cross-site scripting (XSS) Cross-site request forgeries (CSRF) Remote file uploads, (buffer overflow, SQL injection, etc.) Trust between the client’s machine and the web applications. CSCE 548 - Farkas39

40. How to avoid XSS? Scrub all input Escape output for display Use trusted solutions when available Use separate variables for scrubbed input CSCE 548 - Farkas40

41. Cross-site request forgery Exploits the trust between server and client machine Mostly http requests and responses Based on how web pages are delivered along with images and other web content CSCE 548 - Farkas41

42. Prevent CSRF Require verification and stages for sensitive applications Use anti-CSRF tokens in your forms and processing Use post as the mean of taking form input – Get: encodes the data of the form into the url of the recipient, appending it to the query string of the request – Post: encodes it as a message CSCE 548 - Farkas42

43. Unrestricted file upload Users may upload malicious files Uploaded files can be called by a url (if stored on the web server) Example: php – Embedded in image files – Compile php code CSCE 548 - Farkas43

44. Avoid file upload problems System should determine file name Do not allow users to access the folders where content is uploaded Parse file extensions carefully or set your own file parser White list extensions Be secure with the.htaccess file (controls accesses to the files on the server CSCE 548 - Farkas44

45. Adobe Flash 99% of all internet connected machines use AdobeFlesh No internal automated update capability Flash security policy: Same Origin – Can be modified by XML cross-domain policy declaration Can facilitate XSS, CSRF, DNS rebiding CSCE 548 - Farkas45

46. CSCE 548 - Farkas46 Next Class Student Presentations