Asp Forum - custom behaviour of ObjectList - microsoft.public.dotnet.framework.aspnet.mobile

Reinhold Schalk

12/3/2003 3:50:00 PM

Hello,
i am using the mobile control "ObjectList" to show some data in list view
(binding a DataSet) and after clicking on an item in details view.
This beaviour is exactly what i want to do! But i want to do some custom
layout.
If i use a <DeviceSpecific> and <Choice> control, i am not able to "imitate"
the default behaviour of the ObjectList.
By using a data-binding expression (<%#
(MobileListItem)Container.DataItem...) i can reference the current value,
but the link (to details view) is gone. I can not use a <mobile:link>,
because i do not know where to link to!

Does anybody know, how to get the ObjectList default behaviour, but have the
opportunity to do custom layout?

Many thanks in advance
Reinhold

5 Answers

Sylvain Lafontaine

7/30/2008 5:28:00 AM

As far as know, the recent work attack used a standard method for injecting
javascript into an HTML page via an IFrame and was easily defeated with the
simple use of the Server.HTMLEncode method() and to my knowledge, there is
no way that the simple method of doubling all possible single quotes inside
an alphanumeric value can be circumvented by the hackers; with maybe the
possibility of truncation if the buffer used for the replace command is too
small. (In fact, the recent work attack is not an SQL-Injection per see;
it's an HTML injection attack.).

Of course, we must also not forget about the possibility of numerical
*string* values that might contains something else than a simple number but
as I said, by first parsing them into a numerical variable; we get clear of
this possible loophole.

However, I agree with you that parameters should always be used whenever
possible and that in most case, taking the decision of simply dropping
anything containing binary data, escape sequences and comment characters
would be wise. Some people will parse these things out; in my opinion,
dropping the whole thing would be even better.

Here are two more reference for the OP:
http://msdn.microsoft.com/en-us/library/ms1...
http://msdn.microsoft.com/en-us/library/ms9...

--
Sylvain Lafontaine, ing.
MVP - Technologies Virtual-PC
E-mail: sylvain aei ca (fill the blanks, no spam please)

"Bob Barrows [MVP]" <reb01501@NOyahoo.SPAMcom> wrote in message
news:uN$XO5c8IHA.5712@TK2MSFTNGP02.phx.gbl...
> Sylvain Lafontaine wrote:
>> As others have said, if you take a look with the SQL-Server Profiler,
>> you will see that ADO use parameterized queries to execute these
>> commands.
>> Practically, the only way that you can be hurt by SQL injection
>> attack is when you are dynamically building your one sql strings. For
>> alphanumeric string values - that are to be enclosed between
>> single quotes - all you have to do is to replace any enclosed single
>> quote with two single quotes by using the replace command. Very easy
>> to do. Of course, if you are using double quotes as the string
>> delimiter then these are those that you must double using the replace
>> command.
>
> This is not enough. There are several documented techniques for hackers to
> use to get around this simplistic strategy. SQL can be injected without a
> single quote character involved. In fact, the recent worm attack that hit
> so many websites in the last month used one of those techniques.
> If parameters are possible, forget attempting to excape strings: use
> parameters. If dynamic sql is necessary, validate data against a list of
> acceptable entries, rather than attempting to outthink the bad guys.
>
>
> --
> Microsoft MVP - ASP/ASP.NET
> Please reply to the newsgroup. This email account is my spam trap so I
> don't check it very often. If you must reply off-line, then remove the
> "NO SPAM"
>

(Evertjan)

7/30/2008 6:50:00 AM

Bob Barrows [MVP] wrote on 30 jul 2008 in
microsoft.public.inetserver.asp.db:

> Sylvain Lafontaine wrote:
>> As others have said, if you take a look with the SQL-Server Profiler,
>> you will see that ADO use parameterized queries to execute these
>> commands.
>> Practically, the only way that you can be hurt by SQL injection
>> attack is when you are dynamically building your one sql strings. For
>> alphanumeric string values - that are to be enclosed between
>> single quotes - all you have to do is to replace any enclosed single
>> quote with two single quotes by using the replace command. Very easy
>> to do. Of course, if you are using double quotes as the string
>> delimiter then these are those that you must double using the replace
>> command.
>
> This is not enough. There are several documented techniques for
> hackers to use to get around this simplistic strategy. SQL can be
> injected without a single quote character involved. In fact, the
> recent worm attack that hit so many websites in the last month used
> one of those techniques. If parameters are possible, forget attempting
> to excape strings: use parameters. If dynamic sql is necessary,
> validate data against a list of acceptable entries, rather than
> attempting to outthink the bad guys.

As first "line" of defence,
let us all change the probably still common:

sql = "... WHERE id = " & request.querystring("id")

to

sql = "... WHERE id = " & CInt(request.querystring("id"))

or even better, since it will not show the sql in the errorline,if an
errorline is still shown:

temp = CInt(request.querystring("id"))
sql = "... WHERE id = " & temp

and search our ancient, be it still in use, pages for those instances.

--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

Bob Barrows [MVP]

7/30/2008 10:33:00 AM

Sylvain Lafontaine wrote:
> As far as know, the recent work attack used a standard method for
> injecting javascript into an HTML page via an IFrame and was easily
> defeated with the simple use of the Server.HTMLEncode method()

No, that was the second stage of the two-stage attack; in the first stage
the bot used sql injection to declare and open a cursor to update every
"string" field in the database, appending its js payload to the current
contents:
http://blogs.technet.com/neilcar/archive/2008/03/15/anatomy-of-a-sql-injection-incident-part-2...

--
Microsoft MVP - ASP/ASP.NET
Please reply to the newsgroup. This email account is my spam trap so I
don't check it very often. If you must reply off-line, then remove the
"NO SPAM"

Sylvain Lafontaine

7/30/2008 4:33:00 PM

First, thanks for the info. Second, even in this case, the sql portion of
this attack would have been easily defeated by using the replace method for
the embedded single quotes.

--
Sylvain Lafontaine, ing.
MVP - Technologies Virtual-PC
E-mail: sylvain aei ca (fill the blanks, no spam please)

"Bob Barrows [MVP]" <reb01501@NOyahoo.SPAMcom> wrote in message
news:%23ArDT%23i8IHA.4988@TK2MSFTNGP04.phx.gbl...
> Sylvain Lafontaine wrote:
>> As far as know, the recent work attack used a standard method for
>> injecting javascript into an HTML page via an IFrame and was easily
>> defeated with the simple use of the Server.HTMLEncode method()
>
> No, that was the second stage of the two-stage attack; in the first stage
> the bot used sql injection to declare and open a cursor to update every
> "string" field in the database, appending its js payload to the current
> contents:
> http://blogs.technet.com/neilcar/archive/2008/03/15/anatomy-of-a-sql-injection-incident-part-2...
>
> --
> Microsoft MVP - ASP/ASP.NET
> Please reply to the newsgroup. This email account is my spam trap so I
> don't check it very often. If you must reply off-line, then remove the
> "NO SPAM"
>

Daniel Crichton

7/30/2008 4:44:00 PM

Notice that there are 2 versions - one that starts with a single quote, and
one that does not. The latter form relied on using a numeric value that was
being passed into a SQL string without validation. It was easily defeated by
simply checking the value is a number before using it, or converting the
querystring value to a number (eg using CInt or CLng) prior to using in
dynamic SQL, but took advantage of a lot of programmers having put no
validation checks into their code. While the replace with single quotes
works for one version, it doesn't for the other.

Dan

Sylvain wrote on Wed, 30 Jul 2008 12:33:12 -0400:

> First, thanks for the info. Second, even in this case, the sql portion
> of this attack would have been easily defeated by using the replace
> method for the embedded single quotes.

> --
> Sylvain Lafontaine, ing.
> MVP - Technologies Virtual-PC
> E-mail: sylvain aei ca (fill the blanks, no spam please)

> "Bob Barrows [MVP]" <reb01501@NOyahoo.SPAMcom> wrote in message news:%23ArDT%23i8IHA.4988@TK2MSFTNGP04.phx.gbl...
>> Sylvain Lafontaine wrote:
>>> As far as know, the recent work attack used a standard method for
>>> injecting javascript into an HTML page via an IFrame and was easily
>>> defeated with the simple use of the Server.HTMLEncode method()

>> No, that was the second stage of the two-stage attack; in the first
>> stage the bot used sql injection to declare and open a cursor to
>> update every "string" field in the database, appending its js
>> payload to the current contents:
>> http://blogs.technet.com/neilcar/archive/2008/03/15/anatomy...
>> injection-incident-part-2-meat.aspx

>> --
>> Microsoft MVP - ASP/ASP.NET
>> Please reply to the newsgroup. This email account is my spam trap so
>> I don't check it very often. If you must reply off-line, then remove
>> the "NO SPAM"

microsoft.public.dotnet.framework.aspnet.mobile

custom behaviour of ObjectList

Reinhold Schalk

Sylvain Lafontaine

(Evertjan)

Bob Barrows [MVP]

Sylvain Lafontaine

Daniel Crichton

x Login to ForumsZone