Hi,
See the previous thread Request.Form abuse in this newsgroup...
I'm looking for a simple and efficient way to prevent people hijacking the
<formtags on my websites and using them to send spam. I would imagine
they're using the HttpWebRequest method for this.
Essentially, it would require a property on a WebForm that indicates whether
it is *only* for PostBack (true by default, but configurable), which would
have any client POST request which is not from the URL of the page itself
would be ignored.
Alternatively, a "global" flag which could be set in web.config.
I think this would be of great benefit to everyone, as this sort of attack
is clearly becoming more and more common.
Does anyone have any suggestions for a good way to implement this?
I'm sure, as a group, we could come up with something really solid which
would help us all - as Juan said, we're all up the creek with this.
Let's get our thinking caps on, guys...
Who knows - we might even let Microsoft use it in a future version of
ASP.NET... ;-)
Mark
12  2130 
"Mark Rae" <ma**@markNOSPA Mrae.comwrote in message
news:OU******** ******@TK2MSFTN GP04.phx.gbl...
Hi,
See the previous thread Request.Form abuse in this newsgroup...
I'm looking for a simple and efficient way to prevent people hijacking the
<formtags on my websites and using them to send spam. I would imagine
they're using the HttpWebRequest method for this.
Essentially, it would require a property on a WebForm that indicates
whether it is *only* for PostBack (true by default, but configurable),
which would have any client POST request which is not from the URL of the
page itself would be ignored.
Alternatively, a "global" flag which could be set in web.config.
I think this would be of great benefit to everyone, as this sort of attack
is clearly becoming more and more common.
Does anyone have any suggestions for a good way to implement this?
I'm sure, as a group, we could come up with something really solid which
would help us all - as Juan said, we're all up the creek with this.
Let's get our thinking caps on, guys...
Who knows - we might even let Microsoft use it in a future version of
ASP.NET... ;-)
Mark
I'll start with a suggestion and see where the holes spring from!
A list of forms that are only subject to postback on submission is easy to
create and could reside in web.config (or anywhere cachable) - crude, but we
can think of another way later. A begin request intercepted in an
ihttpmodule could verify the ispostback property of any request. If its not
a postback form, and is in the list of forms that require postback then dump
the request and return a redirect to some random fictitious URL. It wont
even touch the actual form being requested.
--
--
Regards
John Timney (MVP)
VISIT MY WEBSITE: http://www.johntimney.com http://www.johntimney.com/blog
"John Timney (MVP)" <x_****@timney. eclipse.co.ukwr ote in message
news:9c******** *************** *******@eclipse .net.uk...
John,
A list of forms that are only subject to postback on submission is easy to
create and could reside in web.config (or anywhere cachable) - crude, but
we can think of another way later. A begin request intercepted in an
ihttpmodule could verify the ispostback property of any request. If its
not a postback form, and is in the list of forms that require postback
then dump the request and return a redirect to some random fictitious URL.
It wont even touch the actual form being requested.
I like it!
If we were to use a real rather than a fictitious URL for the redirect, do
you think that would be a good thing or a bad thing? I guess it would be a
bad thing because (I suppose) it would look to the target URL that the
posting was coming from our IP address rather than the spammer's IP
address...
Being based in the UK, I think I would find it rather satisfying if the
spammers suddenly found themselves trying to post here: http://www.met.police.uk/computercrime/
:-)
I think I would redirect them to a large video file on one of the online
video places which may well crash their program with the size of the
response. That said, its not fair to send them to someone else server and
use their bandwidth, hence the suggestion of the fictitious URL.
On detecting an attempt to use a postback it would actually be quite easy to
also block their IP real time in the filter, so any future request from them
was always dropped or always resulted in a large video being sent as the
response. It would be a one hit system.
I've done most of what we're dicsussing in the past on net 1.1, but not for
this reason so the code should be very easy to put together....... I'm still
waiting for people to find holes in the suggestion though - Juans a likely
candidate for sinking my idea......lol
--
--
Regards
John Timney (MVP)
VISIT MY WEBSITE: http://www.johntimney.com http://www.johntimney.com/blog
"Mark Rae" <ma**@markNOSPA Mrae.comwrote in message
news:ed******** ******@TK2MSFTN GP03.phx.gbl...
"John Timney (MVP)" <x_****@timney. eclipse.co.ukwr ote in message
news:9c******** *************** *******@eclipse .net.uk...
John,
>A list of forms that are only subject to postback on submission is easy
to create and could reside in web.config (or anywhere cachable) - crude,
but we can think of another way later. A begin request intercepted in an
ihttpmodule could verify the ispostback property of any request. If its
not a postback form, and is in the list of forms that require postback
then dump the request and return a redirect to some random fictitious
URL. It wont even touch the actual form being requested.
I like it!
If we were to use a real rather than a fictitious URL for the redirect, do
you think that would be a good thing or a bad thing? I guess it would be a
bad thing because (I suppose) it would look to the target URL that the
posting was coming from our IP address rather than the spammer's IP
address...
Being based in the UK, I think I would find it rather satisfying if the
spammers suddenly found themselves trying to post here:
http://www.met.police.uk/computercrime/
:-)
this is what validation of viewstate is for. there is nothing you can about
people that know to do a get before the post to get required hiddenfields.
all screenscrape tools help to do this.
-- bruce (sqlwork.com)
"Mark Rae" <ma**@markNOSPA Mrae.comwrote in message
news:OU******** ******@TK2MSFTN GP04.phx.gbl...
Hi,
See the previous thread Request.Form abuse in this newsgroup...
I'm looking for a simple and efficient way to prevent people hijacking the
<formtags on my websites and using them to send spam. I would imagine
they're using the HttpWebRequest method for this.
Essentially, it would require a property on a WebForm that indicates
whether it is *only* for PostBack (true by default, but configurable),
which would have any client POST request which is not from the URL of the
page itself would be ignored.
Alternatively, a "global" flag which could be set in web.config.
I think this would be of great benefit to everyone, as this sort of attack
is clearly becoming more and more common.
Does anyone have any suggestions for a good way to implement this?
I'm sure, as a group, we could come up with something really solid which
would help us all - as Juan said, we're all up the creek with this.
Let's get our thinking caps on, guys...
Who knows - we might even let Microsoft use it in a future version of
ASP.NET... ;-)
Mark
re:
I'm still waiting for people to find holes in the suggestion though - Juans a likely candidate for
sinking my idea......lol
<lol>
I've been mulling it over, trying to think of a failsafe method...and drawing a blank.
re:
A list of forms that are only subject to postback on submission is easy to create and could reside
in web.config (or anywhere cachable) - crude, but we can think of another way later.
That could get cumbersome.
re:
A begin request intercepted in an ihttpmodule could verify the ispostback property of any request.
Remember that the legal use of the form also involves a postback ( does it, Mark? ),
so you can't block on the basis of the request being a postback.
re:
If its not a postback form, and is in the list of forms that require postback then dump the
request and return a redirect to some random fictitious URL. It wont even touch the actual form
being requested.
If what I suspect is true, the reverse procedure would work.
As far as I can determine, the crux is that they aren't using postback, but posting directly to the
form.
( Am I right in assuming that ? ) I need a reality check ... ;-)
If that is so, we shouldn't be thinking about payback (as tempting as it is),
but about a solid defense, preferably one which is simple to implement.
So, if the request being a postback is a requirement, would checking for IsPostBack and,
if it isn't a Postback, clearing all the fields accomplish what we want ?
If the hackers/spammers are *not* using Postback (I am assuming that...) that should work.
The key is whether they *are* POSTing without having requested the page.
If not, then I need to think about this some more.
re:
On detecting an attempt to use a postback it would actually be quite easy to also block their IP
real time in the filter
Wouldn't blocking postbacks also block the intended legal use of the feedback form ?
Juan T. Llibre, asp.net MVP
asp.net faq : http://asp.net.do/faq/
foros de asp.net, en español : http://asp.net.do/foros/
=============== =============== =====
"John Timney (MVP)" <x_****@timney. eclipse.co.ukwr ote in message
news:cZ******** *************** *******@eclipse .net.uk...
>I think I would redirect them to a large video file on one of the online video places which may
well crash their program with the size of the response. That said, its not fair to send them to
someone else server and use their bandwidth, hence the suggestion of the fictitious URL.
On detecting an attempt to use a postback it would actually be quite easy to also block their IP
real time in the filter, so any future request from them was always dropped or always resulted in
a large video being sent as the response. It would be a one hit system.
I've done most of what we're dicsussing in the past on net 1.1, but not for this reason so the
code should be very easy to put together....... I'm still waiting for people to find holes in the
suggestion though - Juans a likely candidate for sinking my idea......lol
--
--
Regards
John Timney (MVP)
VISIT MY WEBSITE:
http://www.johntimney.com
http://www.johntimney.com/blog
"Mark Rae" <ma**@markNOSPA Mrae.comwrote in message news:ed******** ******@TK2MSFTN GP03.phx.gbl...
>"John Timney (MVP)" <x_****@timney. eclipse.co.ukwr ote in message
news:9c******* *************** ********@eclips e.net.uk...
John,
>>A list of forms that are only subject to postback on submission is easy to create and could
reside in web.config (or anywhere cachable) - crude, but we can think of another way later. A
begin request intercepted in an ihttpmodule could verify the ispostback property of any request.
If its not a postback form, and is in the list of forms that require postback then dump the
request and return a redirect to some random fictitious URL. It wont even touch the actual form
being requested.
I like it!
If we were to use a real rather than a fictitious URL for the redirect, do you think that would
be a good thing or a bad thing? I guess it would be a bad thing because (I suppose) it would look
to the target URL that the posting was coming from our IP address rather than the spammer's IP
address...
Being based in the UK, I think I would find it rather satisfying if the spammers suddenly found
themselves trying to post here: http://www.met.police.uk/computercrime/
:-)
I was thinking more along the lines of extending the Page class. I have done
several ASP.Net apps that use an extended Page class for various purposes.
One could easily add a property that handled the situation. But I'm not
saying that the configuration idea is a bad one. I honestly don't know which
would be better.
--
HTH,
Kevin Spencer
Microsoft MVP
Short Order Coder http://unclechutney.blogspot.com
What You Seek Is What You Get
"Juan T. Llibre" <no***********@ nowhere.comwrot e in message
news:eM******** ******@TK2MSFTN GP02.phx.gbl...
re:
>I'm still waiting for people to find holes in the suggestion though -
Juans a likely candidate for sinking my idea......lol
<lol>
I've been mulling it over, trying to think of a failsafe method...and
drawing a blank.
re:
>A list of forms that are only subject to postback on submission is easy
to create and could reside in web.config (or anywhere cachable) - crude,
but we can think of another way later.
That could get cumbersome.
re:
>A begin request intercepted in an ihttpmodule could verify the ispostback
property of any request.
Remember that the legal use of the form also involves a postback ( does
it, Mark? ),
so you can't block on the basis of the request being a postback.
re:
>If its not a postback form, and is in the list of forms that require
postback then dump the request and return a redirect to some random
fictitious URL. It wont even touch the actual form being requested.
If what I suspect is true, the reverse procedure would work.
As far as I can determine, the crux is that they aren't using postback,
but posting directly to the form.
( Am I right in assuming that ? ) I need a reality check ... ;-)
If that is so, we shouldn't be thinking about payback (as tempting as it
is),
but about a solid defense, preferably one which is simple to implement.
So, if the request being a postback is a requirement, would checking for
IsPostBack and,
if it isn't a Postback, clearing all the fields accomplish what we want ?
If the hackers/spammers are *not* using Postback (I am assuming that...)
that should work.
The key is whether they *are* POSTing without having requested the page.
If not, then I need to think about this some more.
re:
>On detecting an attempt to use a postback it would actually be quite easy
to also block their IP real time in the filter
Wouldn't blocking postbacks also block the intended legal use of the
feedback form ?
Juan T. Llibre, asp.net MVP
asp.net faq : http://asp.net.do/faq/
foros de asp.net, en español : http://asp.net.do/foros/
=============== =============== =====
"John Timney (MVP)" <x_****@timney. eclipse.co.ukwr ote in message
news:cZ******** *************** *******@eclipse .net.uk...
>>I think I would redirect them to a large video file on one of the online
video places which may well crash their program with the size of the
response. That said, its not fair to send them to someone else server and
use their bandwidth, hence the suggestion of the fictitious URL.
On detecting an attempt to use a postback it would actually be quite easy
to also block their IP real time in the filter, so any future request
from them was always dropped or always resulted in a large video being
sent as the response. It would be a one hit system.
I've done most of what we're dicsussing in the past on net 1.1, but not
for this reason so the code should be very easy to put together....... I'm
still waiting for people to find holes in the suggestion though - Juans a
likely candidate for sinking my idea......lol
--
--
Regards
John Timney (MVP)
VISIT MY WEBSITE:
http://www.johntimney.com
http://www.johntimney.com/blog
"Mark Rae" <ma**@markNOSPA Mrae.comwrote in message
news:ed******* *******@TK2MSFT NGP03.phx.gbl.. .
>>"John Timney (MVP)" <x_****@timney. eclipse.co.ukwr ote in message
news:9c****** *************** *********@eclip se.net.uk...
John,
A list of forms that are only subject to postback on submission is easy
to create and could reside in web.config (or anywhere cachable) -
crude, but we can think of another way later. A begin request
intercepte d in an ihttpmodule could verify the ispostback property of
any request. If its not a postback form, and is in the list of forms
that require postback then dump the request and return a redirect to
some random fictitious URL. It wont even touch the actual form being
requested.
I like it!
If we were to use a real rather than a fictitious URL for the redirect,
do you think that would be a good thing or a bad thing? I guess it would
be a bad thing because (I suppose) it would look to the target URL that
the posting was coming from our IP address rather than the spammer's IP
address...
Being based in the UK, I think I would find it rather satisfying if the
spammers suddenly found themselves trying to post here:
http://www.met.police.uk/computercrime/
:-)
"Juan T. Llibre" <no***********@ nowhere.comwrot e in message
news:eM******** ******@TK2MSFTN GP02.phx.gbl...
I've been mulling it over, trying to think of a failsafe method...and
drawing a blank.
Yes - it's not as straightforward as it sounds...
>A list of forms that are only subject to postback on submission is easy
to create and could reside in web.config (or anywhere cachable) - crude,
but we can think of another way later.
That could get cumbersome.
I would agree.
Remember that the legal use of the form also involves a postback ( does
it, Mark? ),
In this particular case, no it doesn't - that's the weird thing! They have
chosen (at random, I'm sure) a ContentPage whose MasterPage has a <formtag
(obviously, or nothing would work) - but the ContentPage in question doesn't
actually have any data-entry controls nor any submit buttons...
so you can't block on the basis of the request being a postback.
That's right, in this case anyway...
>If its not a postback form, and is in the list of forms that require
postback then dump the request and return a redirect to some random
fictitious URL. It wont even touch the actual form being requested.
If what I suspect is true, the reverse procedure would work.
Yes.
As far as I can determine, the crux is that they aren't using postback,
but posting directly to the form. ( Am I right in assuming that ? ) I
need a reality check ... ;-)
That is correct - I suspect they're using HttpWebRequest or somesuch...
If that is so, we shouldn't be thinking about payback (as tempting as it
is),
but about a solid defense, preferably one which is simple to implement.
Indeed.
So, if the request being a postback is a requirement, would checking for
IsPostBack and,
if it isn't a Postback, clearing all the fields accomplish what we want ?
No, because there aren't any fields to clear! They are adding fields to the
page's Request.Form object dynamically...
>On detecting an attempt to use a postback it would actually be quite easy
to also block their IP real time in the filter
Wouldn't blocking postbacks also block the intended legal use of the
feedback form ?
As above, this isn't a feedback form!!! It has no textboxes or submit
buttons etc. All it has is text and hyperlinks.
"Mark Rae" <ma**@markNOSPA Mrae.comwrote in message
news:%2******** **********@TK2M SFTNGP04.phx.gb l...
"Juan T. Llibre" <no***********@ nowhere.comwrot e in message
news:eM******** ******@TK2MSFTN GP02.phx.gbl...
>I've been mulling it over, trying to think of a failsafe method...and
drawing a blank.
Yes - it's not as straightforward as it sounds...
Has anyone made any further progress with this, because I certainly
haven't...
In fact, as Bruce hinted, I'm not sure that it's even technically
possible...
So, in the meantime, I've gone with an IP blocking solution which has killed
the spammers dead in their tracks.
If anyone's interested, the IP addresses I've caught (so far!) are:
206.83.210.59
216.224.117.178
58.65.233.129
66.79.163.226
I think a list of IP's would probably have to do, and as for blocking them
do it in the module as suggested and actually redirect them to one of the
large download sites. Stop them with some payback. I think I have this
written already on another server - might power it up and ressurect the
code, although it can only be 30 lines or so. Now if you could autoextract
the IP's by identifying they were a nusicance to your site, it would be a
useful little sytem......but I agree with Bruce also, not a lot you can do
other than blocking the IP's.
--
Regards
John Timney (MVP)
VISIT MY WEBSITE: http://www.johntimney.com http://www.johntimney.com/blog
"Mark Rae" <ma**@markNOSPA Mrae.comwrote in message
news:OT******** ********@TK2MSF TNGP03.phx.gbl. ..
"Mark Rae" <ma**@markNOSPA Mrae.comwrote in message
news:%2******** **********@TK2M SFTNGP04.phx.gb l...
>"Juan T. Llibre" <no***********@ nowhere.comwrot e in message
news:eM******* *******@TK2MSFT NGP02.phx.gbl.. .
>>I've been mulling it over, trying to think of a failsafe method...and
drawing a blank.
Yes - it's not as straightforward as it sounds...
Has anyone made any further progress with this, because I certainly
haven't...
In fact, as Bruce hinted, I'm not sure that it's even technically
possible...
So, in the meantime, I've gone with an IP blocking solution which has
killed the spammers dead in their tracks.
If anyone's interested, the IP addresses I've caught (so far!) are:
206.83.210.59
216.224.117.178
58.65.233.129
66.79.163.226
This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics | |
by: J C-W |
last post by:
I have a directory with files (of various formats) contained within a
website which uses PHP to control user access via session variables. I would
like to protect the directory from direct external linking (e.g. prevent
people typing "http://www.mysite.com/protected-directory/file.doc" into the
address bar for example), so that users must log...
|
by: Matt |
last post by:
I have an interactive web page that I need to prevent refreshes on.
The problem is that I want to ALLOW resubmissions, but only via the
submit button. My web page has two forms on it, one form for adding
users, and one form for removing users. I want to be able to add a
user, click the submit button, add another user, click the submit...
|
by: Robb Meade |
last post by:
Hi all,
A recent project that I had finished and went live with no apparant
problems.
My client received an email from a user who mentioned that by accident they
had been typing (over the querystring I guess), and the url had become
default.asp?pageid='asd
|
by: Fred |
last post by:
Hi out there,
I have problems finding a way to warn a user that
another user intends soon to update the same specific row.
Let me explain.
User 1 get to a JSP "update customer record" page.
- The page does a read of the existing record and
loads it into the gui fields for edit.
|
by: David Hane |
last post by:
Hi all,
I would like give users the ability to experiment with complex queries but
I'm worried about them creating queries that will bog down the server.
Does anyone have any ideas for preventing a runaway process?
I'd like to empower my users AND keep my server online :-)
Thanks!
| | |
by: Iain |
last post by:
I would like to prevent the user from closing MDI child windows. However, I
would like them to be able to minimize and maximize them.
Setting the Control Box to false removes the minimize and maximize too.
An obvious thing to do is to handling the CLosing event and cancel it.
Sadly, if you do this the main Form refuses to shut down...
...
|
by: MarkMurphy |
last post by:
In a barebones website with one page, checking
HttpContext.Current.Request.UserLanguages.Length in Page_Load of an
ASPX page in the VS IDE in codebehind shows a value of 1. Then when I
refresh the page with F5 from the browser it goes to the expected 16
-- the number of languages I have defined in IE6. I'm globalizing a
site and could swear...
|
by: Mark Rae |
last post by:
Hi,
Because all my public sites are hosted with a 3rd-party ISP and, therefore,
I don't have access to their server's EventLog etc, every error is emailed
to me.
Recently, I've been getting inundated with errors like the one below.
Obviously, spammers are trying to use a page on the site to send out Viagra
emails etc, but I was curious...
|
by: tatata9999 |
last post by:
Thanks.
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However, people are often confused as to whether an ONU can Work As a Router. In this blog post, we’ll explore What is ONU, What Is Router, ONU & Router’s main...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers, it seems that the internal comparison operator "<=>" tries to promote arguments from unsigned to signed.
This is as boiled down as I can make it. ...
| | |
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows Update option using the Control Panel or Settings app; it automatically checks for updates and installs any it finds, whether you like it or not. For...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each protocol has its own unique characteristics and advantages, but as a user who is planning to build a smart home system, I am a bit confused by the...
|
by: conductexam |
last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and then checking html paragraph one by one.
At the time of converting from word file to html my equations which are in the word document file was convert...
|
by: TSSRALBI |
last post by:
Hello
I'm a network technician in training and I need your help.
I am currently learning how to create and manage the different types of VPNs and I have a question about LAN-to-LAN VPNs.
The last exercise I practiced was to create a LAN-to-LAN VPN between two Pfsense firewalls, by using IPSEC protocols.
I succeeded, with both firewalls in...
|
by: adsilva |
last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
|
by: 6302768590 |
last post by:
Hai team
i want code for transfer the data from one system to another through IP address by using C# our system has to for every 5mins then we have to update the data what the data is updated we have to send another system
| | |
by: bsmnconsultancy |
last post by:
In today's digital era, a well-designed website is crucial for businesses looking to succeed. Whether you're a small business owner or a large corporation in Toronto, having a strong online presence can significantly impact your brand's success. BSMN Consultancy, a leader in Website Development in Toronto offers valuable insights into creating...
| |
