CSCE 548 Secure Software Development Web Application Security

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, Clarke-on-Who-Was-Behind-the-Stuxnet-Attack.html Clarke-on-Who-Was-Behind-the-Stuxnet-Attack.html – N. Antunes, M. Vierira, The Devils Behind Web Application Vulnerabilities, IEEE Computer, Febr. 2012, es es CSCE Farkas2

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: Q2U2SjlOektubnZVUXYyelE6MQ CSCE Farkas3

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

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 Farkas

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

Secure XML Views - Example UC S John Smith UC S Jim Dale UC TS S Harry Green UC 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 phone View over UC data CSCE Farkas

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

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 ?

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, {}) }

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

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

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

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

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

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 Software Security CSCE Farkas

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 Farkas

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 Farkas

20 Improper Error Handling OWASP “A7 Improper Error handling,” 2007, Variants: – Yielding too much information – Ignoring errors – Misinterpreting errors – Using useless error values – Handling the wrong exception – Handling all exceptions together CSCE Farkas

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 Farkas

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 Farkas

23 Input Validation OWASP: CWE-20: improper Input Validation, 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, ads/Exploiting Software-Ch07.pdf ads/Exploiting Software-Ch07.pdf CSCE Farkas

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 Farkas

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 Farkas

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 Farkas

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 Farkas

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

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 Farkas

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 Farkas

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 Farkas

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 Farkas

Web Technologies and Security CSCE Farkas33

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 Farkas34

@ Hidden symbol in URL Change IP address (only the info to the right 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 CSCE Farkas35

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 Farkas36

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 Farkas37

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 Farkas38

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 Farkas39

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

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 Farkas41

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 Farkas42

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 Farkas43

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 Farkas44

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 Farkas45

CSCE Farkas46 Next Class Student Presentations