Download SQL injection

Survey
yes no Was this document useful for you?
   Thank you for your participation!

* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project

Document related concepts

Open Database Connectivity wikipedia , lookup

Clusterpoint wikipedia , lookup

Database model wikipedia , lookup

Transcript
Assure IT’s Quality, Assure IT’s
Security, or Throw IT Out!
Joshua Drummond, Security Architect
Katya Sadovsky, Application Architect
Marina Arseniev, Associate Director of Enterprise Architecture
University of California, Irvine
University of California, Irvine
•
•
•
•
•
•
•
•
•
Located in Southern California
Year Founded: 1965
Enrollment: over 24K students
1,400 Faculty (Academic Senate)
8,300 Staff
6,000 degrees awarded annually
Carnegie Classification: Doctoral/Research – Extensive
Extramural Funding - 311M in 2005-2006
Undergoing significant enrollment growth
Do you know?
•
75% of attacks today happen at the Application (Gartner). Desktop
augmented by Network and then Web Application Security.
•
Many “easy hacking recipes” published on web.
•
3 out of 4 vendor apps we tested had serious SQL Injection bugs!
•
“The cost of correcting code in production increases up to 100
times as compared to in development...”
-
-
•
(1) MSDN (November, 2005) “Leveraging the Role of Testing and Quality
Across the Lifecycle to Cut Costs and Drive IT/Business Responsiveness “
http://msdn.microsoft.com/vstudio/why/testingquality/default.aspx
The cost and reputation savings of avoiding a security breach are
“priceless”
Do you know?
Do you know?
Higher-Ed Security Incidents
http://www.privacyrights.org
People
Date
178,000
380,000
207,000
600,000
98,400
59,000
120,000
106,000
40,000
150,000
72,000
15,000
27,000
42,000
270,000
31,077
April 2004
May 2004
May 2004
Sept 2004
March 2005
March 2005
March 2005
April 2005
April 2005
June 2005
June 2005
June 2005
July 2005
July 2005
July 2005
July 2005
Type
Hacking
Hacking
Stolen laptop/Hack
Hacking
Stolen laptop
Hacking
Hacking
Hacking
Hacking
Dishonest Insider
Hacking
Stolen laptop
Hacking
Hacking
SQL Injection
Hacking
People
Date
Type
36,000
61,709
100,000
49,000
100,000
21,762
2,800
9,100
93,000
38,941
197,000
300,000
41,000
60,000
180,000
14,500
August 2005
August 2005
August, 2005
August 2005
Sept 2005
Sept 2005
October 2005
October 2005
March 2006
April 2006
April 2006
April 2006
March 2006
May 2006
June 2006
Sept 2006
Hacking
Hacking
Hacking
Hacking
Stolen computer
Exposed Online
Exposed Online
Exposed Online
Stolen laptop
Exposed Online
Exposed Online
Exposed Online
Hacking
Hacking
Exposed Online
Hacking
Agenda
•
•
Hacking 101
7 Steps to Assure Software Quality by
Integrating Security into the SDLC
–
•
Sample Checklists
Useful URLs and Q&A
What do Hackers do?
• A few examples of Web application hacks
– File Query
– Browser caching
– Cookie and URL hacks
– SQL Injection
– Cross-site Scripting (# 1 threat today!)
Web File Query
• Directory listing: http://site.com/include/file.js
• Truncation: http://site.com/include
Browser Page Caching
• Be aware of differences between browsers!
• Pages with sensitive data should not be cached: page
content is easily accessed using browser’s history
• Use the following tags to disable page caching:
<META HTTP-EQUIV="Pragma" CONTENT="no-cache">
<META HTTP-EQUIV="Cache-Control" CONTENT=“no-store, no-cache">
<META HTTP-EQUIV="Expires" CONTENT="-1">
- Do-not-cache tags do not apply to binary content
Browser Page Caching
Cookies and URLs
• Sensitive data in cookies and URLs?
– Issues that arise are:
• Information is stored on a local computer (as files or in the browser’s
history)
• Unencrypted data can be intercepted on the network and/or logged
into unprotected web log files
– To prevent unauthorized data access:
• Do NOT store sensitive data of any kind in cookies or URLs
• Use non-persistent cookies (that disappear once a browser is closed)
instead of persistent ones.
• Use HTTP POST instead of GET when submitting data
SQL Injection Attacks
“SQL injection is a security vulnerability that occurs
in the database layer of an application. Its source is
the incorrect escaping of dynamically-generated
string literals embedded in SQL statements. “
(Wikipedia)
Uses SQL script
injection to
access data
Hacker
Web App
SQL Injection Attacks
• Example of attack:
– SQL Query in Web application code:
• “SELECT * FROM users WHERE login = ‘” + userName +
“’ and password= ‘” + password + “’;”
– Hacker logs in as: ‘ or ‘’ = ‘’; -• SELECT * FROM users WHERE login = ‘’ or ‘’ = ‘’; -'; and password=‘’;
– Hacker deletes the users table with: ‘ or ‘’ = ‘’; DROP TABLE users; -• SELECT * FROM users WHERE login = ‘’ or ‘’=‘’; DROP
TABLE users; --'; and password=‘’;
• SQL Injection examples are outlined in:
– http://www.spidynamics.com/papers/SQLInjectionWhitePaper.pdf
– http://www.unixwiz.net/techtips/sql-injection.html
SQL Injection Attacks Demo
SQL Injection Attacks Demo
SQL Injection Attacks Demo
Cross-Site Scripting (XSS)
Attacks
• Malicious code can secretly gather sensitive
data from user while using authentic
website (login, password, cookie)
Cross-Site Scripting (XSS)
Attacks
• Modified URL
– URL parameters are modified on the URL to
contain script code
– Input is not validated and displayed as entered
on the resulting dynamic webpage
Cross-Site Scripting (XSS)
Attacks
XSS: Script Injection Demo
XSS: Script Injection Demo
Preventing
SQL injection and XSS
• SCRUB Error handling
– Error messages divulge information that
can be used by hacker…
• VALIDATE all user entered parameters
– CHECK data types and lengths
– DISALLOW unwanted data (e.g. HTML
tags, JavaScript)
– ESCAPE questionable characters (ticks, -,semi-colon, brackets, etc.)
Agenda
•
•
Hacking 101
7 Steps to Integrate Security into SDLC
–
•
Sample Checklists
Useful URLs and Q&A
Integrating Security into SDLC
Step 1: Training
•
If users are not educated on security concerns,
regulations, and laws, any system will fail.
–
–
•
•
Email will be unintentionally used to transmit regulated
or confidential information
Private data will be entered into a text field
Train Project Leaders, Programmers and
Business units on data security and policy.
Don’t assume technical staff and vendors are
aware of all security issues.
–
Assign appropriately trained staff, mentors/reviewers
Integrating Security into SDLC
Step 2: Requirements
•
Acquisition or development
–
–
Identify Security requirements at requirements gathering
phase
Examples of questions to ask and put into formal
template?
•
•
•
Any personal or confidential data?
Compliance requirements – PCI, SB1386, FERPA, HIPAA?
If 24/7 uptime is required with clustering and load balancing, think
about logging requirements…
–
–
•
do logs need to be centralized? easily audited for forensics analysis?
Retention period? Tamper-proof?
Risk assessment – normal or high risk application?
Requirements Template
1.1
2.5
3.4
5.3
User Classes and Characteristics
<Identify the various user classes that you anticipate will use this product (i.e. users doing
updating vs. users with browse access only). User classes may be differentiated based on
frequency of use, subset of product functions used, technical expertise, security or privilege
levels, educational level, or experience...>
Design and Implementation Constraints
<Describe any items or issues that will limit the options available to the developers. These might
include: …corporate or regulatory policies; …interfaces to other applications; specific
technologies, tools, and databases to be used; …communications protocols; security
considerations.>
Communications Interfaces
<Describe the requirements associated with any communications functions required by this
product, including e-mail, web browser, network server communications protocols, electronic
forms, and so on. Define any pertinent message formatting. Identify any communication
standards that will be used, such as FTP or HTTP. Specify any communication security or
encryption issues, data transfer rates, and synchronization mechanisms.>
Security Requirements
<Specify any requirements regarding security or privacy issues surrounding use of the product or
protection of the data used or created by the product. Define any user identity authentication
requirements. Refer to any external policies or regulations containing security issues that affect
the product. Define any security or privacy certifications that must be satisfied.>
ASP Vendor Security Checklist








What certification or audits does the
University have that the system will be
managed per our guidelines and
contract agreement?
How do you manage the system for
detection of intrusion.
How often is the system patched, by
whom and when?
How are we notified if system security
is breached? Notification handling?
How is data purged from the vendor's
hardware?
How are disks, tapes, or computers
that might store sensitive data
disposed of? Are the media erased
before disposal or reuse?
Where is the hardware location? Is it
inside or outside of the United States?
Is it subject to our laws?
Are the personnel who administer and
use the hardware located within the
United States and subject to our laws?






Is data encrypted?
If private data is transmitted, either via
Internet, on CD-ROM or file transfer, is it
encrypted?
Is SSL enabled to the application so that
traffic over the Internet, including
authentication is secure and private?
Data loss, data backups: what are the
guarantees? Are backups stored offsite?
If backups have sensitive data, are the
backups encrypted? Can we store the
backup at UCI? How about disaster
recovery planning?
How is the hardware or database
distributed by the vendor among
customers? Is one hardware used for all
customers? Is a single database used for
all customers or does each customer
have a private database?
How are user accounts managed?
Integrating Security into SDLC
Step 3: Architecture and Design
•
•
Dedicate a Security role in your organization
Security Architecture must
– address and support multiple layers of protection,
including database, network level, operating system,
and application level security
– be flexible to support the introduction and/or integration
of new technologies
– provide a modular approach to authentication,
authorization, and audit
Security Architecture – Multi-layer
Policies, Standards, Procedures, Technical Reference Architecture
Approved Tools and Lifecycle
Exceptions by Approval
Regularly reviewed
User
Identity Management
Authentication
Education
Network/Web
Account Admin
Firewalls, Encryption
Logging/Auditing
Application
Authorization
Logging/Audit
Test Tools
Data
Authorization
Logging/Audit
Encryption,Inventory
Operations
Backups (incl off-site)
Logging/Audit
Disaster Recovery
Security Architecture Lifecycle –
focus on Standardization
Security Architecture Design
•
•
•
•
•
•
Consider security during initial system design
Delegate access control as appropriate
Centralize security policy, maintenance operation
and oversight functions
Assign security levels consistently and at the
lowest level of access required by the individual
Identify vulnerable points. Design and reuse
common and tested components
Consolidate storage of sensitive data – important!
Storing sensitive data
• AVOID storing sensitive data if at all possible!
• If you have to store sensitive data:
–Encrypt table records and/or files that contain:
• password, SSN, home phone/address, credit card, bank
account, Driver's License, non-public student or employee data,
or FERPA blocked student data
–Encrypt storage at database/file and application layer
• Database encryption is not enough! Protects from lost/stolen
disk or backup, not from SQL-Injection hack attack
• Multi-layer security protection - User account breach won’t allow
decryption
–Use encrypted transmission for data retrieval and
modification
Data modelling
• When designing database tables:
–No confidential data elements should be used as
keys in tables (e.g. SSN)
–Normalize to consolidate confidential data into a
single table
• Audit ONE table, not many
• Encrypt ONE table, not many
• Mock intruder alert drills and prepare!
• Review logs for forensics capability
Integrating Security into SDLC
Step 4: Implementation
Implementation/Acquisition – make security “routine”
•
Require code reviews of all security and database code
•
Require developers to build unit test harnesses
–
•
Require developers to reuse security components
–
•
Jtest, AppScan, WebInspect, Nessus, database security scanning
Schedule network & configuration vulnerability scanning
–
•
•
•
Single-signon, authorization API, user identity objects
Automate nightly code and application security scanning
–
•
Junit
Foundstone, Sophos virus scans, Tripwire
De-identify confidential test data
Write and use manual security test procedures
Perform concurrency and stress testing
–
Jmeter, OpenSTA (100s of concurrent virtual test user load)
Sample Checklists
•
Portal (SNAP) SDLC Documentation
–
SDLC Process
•
•
–
–
–
–
–
–
Requirements – Sections of our template address specific security
requirements.
Project Plan includes review schedule.
Development / Vendor Selection Guidelines
Database Review, SQL Server Setup Checklist
Code Review Checklist, Test Templates
Security Manual Test Procedure
Security Assessment and Checklists
Architecture Review
Integrating Security into SDLC
Step 5: Deployment
•
•
•
Create secured test and production environment
Cross train Helpdesk, Sys Admin, support staff
“Market” Application security risks and policy
– Consider policy to disallow confidential data on laptops or other
portable devices
•
•
Professionally administered system and data backups?
– backups identify compromised individuals
– Off-site backups? Where? At home?
Disaster recovery plans?
Integrating Security into SDLC
Step 6: Operations/Maintenance
•
•
•
Catalogue and inventory use of personal data
Repeated “routine” reviews and scanning
Apply all security patches at all architectural layers
in a timely manner
–
•
•
OS, Firewall, Database, Platform
Audit/log access to confidential data
Change control
–
–
–
–
Weekly meeting for all developers and administrators
2 week notice of all turnovers/change required and plans
Oracle Calendar used to publish schedule. Reduced collisions
Fewer “emergency” changes means fewer security vulnerabilities
Integrating Security into SDLC
Step 7: Decommissioning
Decommissioning of Application and Data
• Data
– Retention/preservation compliance?
•
Properly dispose hardware and software
– Does data retention period collide with a software end-oflife? Clipper/DOS 6.2?
– Can OS and hardware run it today if necessary to restore
data? Is data warehousing required?
– Sanitize media professionally, including backups
•
Update catalogue of personal data!
Agenda Summary
•
•
Hacking 101
7 Steps to Assure Software Quality by
Integrating Security into SDLC
–
•
Sample Checklists
Useful URLs and Q&A
Q&A
Useful Links
• Campus security site:
http://www.security.uci.edu
• AdCom's application security checklist:
http://snap.uci.edu/viewXmlFile.jsp?resourceID=1440
• AdCom's Java code review checklist:
http://snap.uci.edu/viewXmlFile.jsp?resourceID=1529
• Open Web Application Security Project
(OWASP): http://www.owasp.org