Getting Started - v4.0

Aug 8, 2011 at 5:45 PM

All,

I'm starting from square 1... I've installed the library on my machine but if compelled to admit, am a complete noob with the library.
(Perhaps even a noob with respect to Crosssite Scripting in general.)

I've copied the DLLs:
AntiXSSLibrary.dll
HtmlSanitizationLibrary.dll

to the BIN folder on my development server but really, not sure what to next, nor how best to use the library - using the library at all !
I also saw a post here regards moving (antixssmodule.config) to the web server but v4.0 didn't seem to create one... v3.1 did however.

I've also had a look at this: http://msdn.microsoft.com/en-us/library/ms998274.aspx and feel for the most part , my web app doesn't expose a lot of the vulnerabilites expressed... For example , I rarely use RESPONSE.WRITE().

In any event, I have a new app in development in which I'll be working to build in the libray. 
The most obvious place where I'll work to implement the libray regards a form that will heavily depend on user input.
Beyond that, not really sure how to take more advantage of the library.

I DO understand usage of the library is situation; however, are the placed in a web app in which the library should be used that perhaps a noob developer may overlook ?  For example, does one attempt to process every control returned to the server for validation?

Will appreciate any advice you can offer - and thx for reading : )

Coordinator
Aug 8, 2011 at 10:33 PM

Well it depends on

a) Your project type - WebForms or MVC and

b) What you do with any input your receive.

AntiXSS does not provide validation - what it does do is ensure that when you output something to a web page that any attempted XSS payload is properly handled. So, when you process the form and spit results back to the user then any output that has come from input should be encoded.

Aug 8, 2011 at 10:49 PM

thank you for the prompt reply!
- Your project type: WebForms
- input your receive: db storage

Digging deeper I believe I see this a bit clearer.  I will be untrusting of data I push to the client and working to Encode all of it appropriately.  On the flip, I'll also be expected to store user data into a back end database.

Understood therefore that Validation is not provided... still however seems that I am missing a few puzzle pieces to round out my understanding regards all that is going on here.... Does for example the library come into play on a postback ?  That is, can the library be used to Encode data passed back to the server and, would I really want to do that?  If situation, can you site why I might?

thx again for your reply : )

 

Coordinator
Aug 8, 2011 at 10:59 PM

Please understand I can't give specifics, only general advice.

You should be encoding at output only.

There is no interception of postbacks - AntiXSS just does encoding. You must manually call it. It does not work client side, so there is no encoding of data that is sent/passed back to the server.

Aug 8, 2011 at 11:29 PM
Edited Aug 8, 2011 at 11:29 PM

No problem!

I suppose when I was introduced to the tool , I had an expectation that it worked both ways - that's all.  Your clarification does truly help!

Perhaps off topic, I uderstand that I should Encode whatever is sent from the client to the server.   If I am not using this library to Encode on the client side (again please forgive my ignorance), something like HttpUtility.HtmlEncode  I would do instead on the client side, then HttpUtility.HtmlDecode on the server side ?

Not trying to press you on specifcs but instead trying to get an overall grasp per the flow of moving data between client and server with respect to the above.  To date, the development work I've done was (and is) inTRAnet based rather than being exposed to the outside world.  I'm finding myself trying to build fenses in a world where boundaries are almost never crossed - that I know of anyway - and it's hard to visual threats that I seem not to experience first hand.

 

 

 

Coordinator
Aug 9, 2011 at 12:38 AM

It doesn't need to work both ways - the browser encodes data before it is sent , and ASP.NET will decode it. So you don't need to do anything on the client side at all, except properly encode any output that has come from user input, so, for example < gets output as &lt;