.NET2 Web site form - can it be Broken?

[Durbs]

the dynamic SQL thing is a myth and i do wish people wouldn't propagate it. the issue isn't SPs versus dynamic SQL, the issue is parameterisation (you need it).

???? Explain. What i'd originally meant was the old dynamically written inline SQL but if you look at the following example of a sp taken off the web:

CREATE PROCEDURE search_orders @custid nchar(5) = NULL,
@shipname nvarchar(40) = NULL AS
DECLARE @sql nvarchar(4000)
SELECT @sql = ' SELECT OrderID, OrderDate, CustomerID, ShipName ' +
' FROM dbo.Orders WHERE 1 = 1 '
IF @custid IS NOT NULL
SELECT @sql = @sql + ' AND CustomerID LIKE ''' + @custid + ''''
IF @shipname IS NOT NULL
SELECT @sql = @sql + ' AND ShipName LIKE ''' + @shipname + ''''
EXEC(@sql)


If you set @shipname to: ' DROP TABLE Orders --

Then @Sql is executed as:

SELECT * FROM dbo.Orders WHERE 1 = 1 AND ShipName LIKE '' DROP TABLE orders --'

But, yes, you are right, paramatization (sp?) is the key but do you not class the above as dynamic SQL cos i do?

[lambrini_socialist]

do you not class the above as dynamic SQL cos i do?

what i class the above as will get me banned!

[Durbs]

It would be a pretty bad sp to have in your app granted but i'll wager theres endless apps out there on the ole interyweb using sh1te like that.

[NickFitz]

Also use the length= attribute for your textboxes to prevent people pasting huge amounts of text in to force DB errors.

The maxlength (not length) attribute is useful for the common case of a punter with a browser, but it doesn't stop me doing something like typing:

javascript:void(document.forms[0].element[0].value="verylongstring")

into the location bar before hitting submit; last time I checked, browsers didn't enforce maxlength against that.

(Actually, the first time it occurred to me to try that, circa 1998, I forgot I was posting to the live server and crashed Oracle Web Access on a live site - still, the server restarted itself within a few minutes )

However, any malicious tool will write whatever length of content it wishes, despite the attributes of the form elements - if one is trying to break a site, one doesn't use a browser.

Remind me to tell you sometime about my XSS attack via putting JavaScript code into the User-Agent HTTP header...

[Jaws]

It would be a pretty bad sp to have in your app granted but i'll wager theres endless apps out there on the ole interyweb using tulipe like that.

I've actually seen that numerous times and it makes me furious!

[DimPrawn]

The only safe and secure solution is to have all webservers connected only to printers and not databases.

Then someone in India who we trust can read the printout and if it is acceptable, type it live into the database using a query editor.

HTH

[wxman]

Demo Guestbook Here

This is a case of diminishing returns (protection of the web form) but this thread has certainly focused my attention on areas to look at.

OK I concede that client side verification can be circumvented, but I also do some Server side checking before I even go any near passing values to the SP for writing to the DB.

Client Side
Regex, textbox length, Simple verification code needs to be typed before submit is allowed.

Server Side
Is pageValid check from client verification?
Is field size < n Chr$?
Pass field values to object (but all the types are string)
** to Do. Is email address? Is URL?, Flood control – disable DB write is excessive number of requests are made

Writing to DB
Parameterised Stored Proc with limited field size
Tightened security on DB privileges.

Finally each and every entry has to be approved (via a maintenance page) before public viewing is allowed.

I know that the page verification code can be circumvented – but it will required effort on behalf of the "baddy" to do so!


Any thing else

[DimPrawn]

Demo Guestbook Here

This is a case of diminishing returns (protection of the web form) but this thread has certainly focused my attention on areas to look at.

OK I concede that client side verification can be circumvented, but I also do some Server side checking before I even go any near passing values to the SP for writing to the DB.

Client Side
Regex, textbox length, Simple verification code needs to be typed before submit is allowed.

Server Side
Is pageValid check from client verification?
Is field size < n Chr$?
Pass field values to object (but all the types are string)
** to Do. Is email address? Is URL?, Flood control – disable DB write is excessive number of requests are made

Writing to DB
Parameterised Stored Proc with limited field size
Tightened security on DB privileges.

Finally each and every entry has to be approved (via a maintenance page) before public viewing is allowed.

I know that the page verification code can be circumvented – but it will required effort on behalf of the "baddy" to do so!


Any thing else

The ASP.NET validation controls generate client AND server-side validation code, so even if the client side is bypassed, as long as you check Page.IsValid before submitting the data, you should be okay.

To be sure, I run all input serverside through a regex replace to remove characters I would not expect in given fields. Eg. remove < > ? % & * etc etc from fields that contain things like names addresses, then Proper (title) case them using a very clever routine as people tend to input in all upper-case for some reason.

[Durbs]

Demo Guestbook Here

This is a case of diminishing returns (protection of the web form) but this thread has certainly focused my attention on areas to look at.

OK I concede that client side verification can be circumvented, but I also do some Server side checking before I even go any near passing values to the SP for writing to the DB.

Client Side
Regex, textbox length, Simple verification code needs to be typed before submit is allowed.

Server Side
Is pageValid check from client verification?
Is field size < n Chr$?
Pass field values to object (but all the types are string)
** to Do. Is email address? Is URL?, Flood control – disable DB write is excessive number of requests are made

Writing to DB
Parameterised Stored Proc with limited field size
Tightened security on DB privileges.

Finally each and every entry has to be approved (via a maintenance page) before public viewing is allowed.

I know that the page verification code can be circumvented – but it will required effort on behalf of the "baddy" to do so!


Any thing else

I think with that lot, your client should be assured that you have taken all reasonable precautions.

At the end of the day, you WILL get idiots probing it but the vast bulk of these will be automated tools looking for common stupid mistakes.

Also the tip above is good, there is no overhead in using a replace function against input of the size coming from a guestbook form. I always do this and strip common injection characters from user input even if its not an issue due to paramatisation - belt and braces approach.

[NickFitz]

Demo Guestbook Here

I made a post with the comment

testing

and got the "thank you" page. However, when I tried an XSS attack by using exactly the same details, but with the comment

testing <script>alert('pwned');</script>

I got a server error.

Posting the comment

'hello'

worked, so it seems to be be the <script> tags, not the single quotes.