Online ColdFusion Meetup ColdFusion Application Security: Beyond SQL Injection - PowerPoint PPT Presentation

About This Presentation

Online ColdFusion Meetup ColdFusion Application Security: Beyond SQL Injection


It has a link to a bad joke on a Joke-of-the-Day site. Here is the joke: ... The link the hacker sent, did go to a Joke-of-the-Day page, but the hacker left ... – PowerPoint PPT presentation

Number of Views:270
Avg rating:3.0/5.0
Slides: 61
Provided by: jason220


Transcript and Presenter's Notes

Title: Online ColdFusion Meetup ColdFusion Application Security: Beyond SQL Injection

Online ColdFusion MeetupColdFusion Application
Security Beyond SQL Injection
  • January 22nd, 2009
  • Jason Dean
  • http//

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?)
  • Veteran of the U.S. Coast Guard

Today We'll Look At
  • Cookie Security
  • Request Forgeries
  • Password Security
  • Session Management
  • Cross-Site Scripting XSS

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?

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 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 It is a flag that tells the
    browser to only submit the cookie via HTTP
    requests, which means it cannot be access via

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
  • When a blogger logs in they could get a cookie
  • 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
  • A malicious user could create a new account
    called Then invite
    the other bloggers from
  • When the other bloggers visit, if they have
    current cookies for, 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

HTTPOnly Flag
  • Used to specify when a cookie can be accessed
  • If set, the cookie can only be used in HTTP
  • 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

ltcfheader name"Set-Cookie" value"firstnameJason
Session Token Cookies
  • By default, ColdFusion does not make Session
    Token Cookies very secure
  • Domain attribute is handled well, if
    this.setClientCookies true in
  • 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.

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" /gt ltcfheader name"Set-cookie"
value"CFTokensession.cftokenpath/test/dom" /gt
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
  • JsessionIDs seem considerably harder to
  • 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
/gt ltcfheader name"Set-cookie"
h/test/ domain.12robots.awesomecoldfusionblo
ggers.comHTTPOnly" /gt
ltcfset "cookieTest" /gt ltcfset
this.sessionManagement true /gt ltcfset
this.setClientCookies false /gt
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

That was confusing
  • How about an Example?
  • Our Hypothetical website http//
  • Has an administrator only section for maintaining
  • 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?

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

What happened?
  • The email Bob received wasn't from Kay in
  • ltDramatic Pausegt
  • It was from a Hacker who spoofed Kay's email
  • 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//
What happened?
  • When Bob viewed that page the ltimg /gt tag went
    looking for the src resource and made the
  • 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//
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

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 lt/scriptgt
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
  • 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
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
How do we fix it?
  • Another option is to ask for a second
  • Prompt Are you sure? using server-side logic
  • Maybe even require them to enter their password

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

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

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

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

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

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
  • A strong enough hash will have very few

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
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
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
  • 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
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
Stronger Hashing Example MD5 Result
  • 472D46CB829018F9DBD65FB8479A49BB
  • CBD672C9AAF85A22968C7BCF9FF90EED
  • 10F1C46CAF873486E530570E7A298BBB

Stronger Hashing Example SHA-256 Result
  • 7FA8A6E9FDE2F4E1DFE6FB029AF47C9633D4B7A616A42C3B28
  • 0DBDC9C5C4E9B4B11FECFAC0247A0E0F0E810A7BD0AD3EEC36
  • E153B4C97FCFAC7016A276461E06504CB9F03B9A3ADF36072E

Stronger Hashing Example SHA-512 Result
  • 27166A235CD42FB7E5A45CB89F542760373DCDC779E1697DB2
  • 0452F87278847018D8E6CC77F4201315AED6928A7A4075B240
  • 4FF17CC3794CAB06B880FDA5507692ADBE5BA74EDFE570611F

  • 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
  • The longer the hash value, the less likely you
    will have collisions.

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

Password Salting
  • What is Salting?
  • Let's first talk about why we need salting
  • Because people make stupid password (i.e.
  • 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
  • Salting ensures that no two hashes in our
    database ever have the same value

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

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
Password Salting ExampleOutput
  • Will result in this output
  • Value 1 Hashed2AC9CB7DC02B3C0083EB70898E549B63
  • Value 2 Hashed2AC9CB7DC02B3C0083EB70898E549B63
  • Value 1 Salted and hashed2DEB5ADAF0854BBBC24DC479
  • Value 2 Salted and Hashed3498DD83CA3F1945D0EE7BE1

ltcfoutputgt Value 1 Hashedhash1ltbr /gt Value 2
Hashedhash2ltbr /gtltbr /gt Value 1 Salted and
Hashedhash1Saltedltbr /gt Value 2 Salted and
Hashedhash2Saltedltbr /gt lt/cfoutputgt
Password Salting Example
  • Value 1 Hashed2AC9CB7DC02B3C0083EB70898E549B63
  • Value 2 Hashed2AC9CB7DC02B3C0083EB70898E549B63
  • Value 1 Salted and Hashed2DEB5ADAF0854BBBC24DC479
  • Value 2 Salted and Hashed3498DD83CA3F1945D0EE7BE1
  • 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

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

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
  • 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
  • Tell story about bad Forgot My Password

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

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

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
  • ColdFusion has two different types of Session
    Tokens available
  • ColdFusion session tokens (Two varieties)
  • J2EE Session tokens

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
  • End user can easily lose their session by messing
    with the URL
  • Session Token will be logged by the web server
  • http//
  • Passing in POST requests (Very difficult to
  • EVERY request from page to page needs to be a
  • Even Navigation
  • ltinput type"hidden" name"cfid"
  • ltinput type"hidden" name"cftoken"
  • 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

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

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 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
  • Use SSL connection to prevent packet sniffing
  • Set cookies to SECURE so they are only sent via
  • 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

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.

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

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

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
  • How do you think the media would report such a

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

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.

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

ColdFusion Script Protect
  • Can be turned on in the Administrator with a
    simple checkbox
  • Can be added or disabled per-application in the
  • 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
  • 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

Character Encoding Function
  • Should be used on content that was created by
  • Will turn your hackers malicious Javascript input
  • 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/
ltscript typetext/javascriptgtalert('Hacked
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
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
  • 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.

  • Please ask your questions now
  • Or feel free to contact me
  • Jason Dean
  • http//
  • AIM IZB Jason
  • Google Chat deanj200
  • http//
Write a Comment
User Comments (0)