this does and if
it could be used as a hacking aid?
Thanks
Robert Harrison
Director of Interactive Services
Austin Williams
Advertising I Branding I Digital I Direct
125 Kennedy Drive, Suite 100 I Hauppauge, NY 11788
T 631.231.6600 X 119 F 631.434.7022
http://www.austin-williams.com
://pastebin.com/2v3PMx4M
We found this in one of our sites which has been getting hacked lately. We
also found a few other infected files which we've cleaned, but this on in
particular was somehow injected into one of our sites. Anyone know what
this does and if it could be used as a hacking aid
a few other infected files which we've cleaned, but this on in
particular was somehow injected into one of our sites. Anyone know what
this does and if it could be used as a hacking aid?
Thanks
Robert Harrison
Director of Interactive Services
Austin Williams
Advertising I Branding I
: Friday, September 06, 2013 10:03 AM
To: cf-talk
Subject: Re: Hacking?
Yes, it certainly can be used by hackers. It can be used to manipulate the file
system, upload files, execute exe's, and run database queries against your
datasources.
This file is most commonly found via the adminapi Hack
Is anyone familiar with this code: http://pastebin.com/2v3PMx4M
I googled the author's name. It's Too Simple File Manager ($15), but this
versions is outdated and has been modified to allow commandline execution and
SQL transactions:
http://www.cftagstore.com/?page=viewTagtagId=290
Ext 1.1 docs are here ...
http://extjs.com/deploy/ext-1.1.1/docs/
Don't forget, the underlying Ajax components are built upon Ext JS 1.1.
There is full API documentation available for 1.1 within the Learning
Center area of the site.
Steve Cutter Blades
Adobe Certified Professional
Has anybody hacked into an HTML cfgrid... in order to format some
numbers. I presume one would need do something with JavaScript somehow
connected to the CFGrid.
I've sucessfully used some sneaky CSS to at least get a right alignment
to my numbers.
.x-grid-col-[col#] {text-align: right;}
Check out this post on how to create a grid renderer for the CF8 Ajax Grid:
http://blog.cutterscrossing.com/index.cfm?mode=entryentry=924FD535-3048-71C2-1732C7C676604ABE
Don't forget, the underlying Ajax components are built upon Ext JS 1.1.
There is full API documentation available for 1.1
-
From: Matt Robertson [EMAIL PROTECTED]
To: CF-Talk [EMAIL PROTECTED]
Sent: Monday, June 23, 2003 3:06 PM
Subject: RE: CFMX Form Submission Hacking.
You're right. That will not protect you, but the problem isn't
Michael's suggestion; its your application design.
Hidden form vars are just flat
perhaps you are right Dave. And Matt.
I'm going to run over to the Is Flash really that good
thread to tell them that using flash solves this issue.
No, unfortunately it doesn't. Flash content is just like any other
client-side content in that respect. If you want to test this theory, just
Does anyone have a quick snippet of code that does a regex match against the referrer
to check if a form was submitted from an internal page (with attention to ports if
possible). Too lazy to write it myself, so hoping someone does this to prevent hacking
of form submissions.
TIA
-Igor
Does anyone have a quick snippet of code that does a regex
match against the referrer to check if a form was submitted
from an internal page (with attention to ports if possible).
Too lazy to write it myself, so hoping someone does this to
prevent hacking of form submissions
[EMAIL PROTECTED]
To: CF-Talk [EMAIL PROTECTED]
Sent: Monday, June 23, 2003 12:24 PM
Subject: CFMX Form Submission Hacking.
Does anyone have a quick snippet of code that does a regex match against
the referrer to check if a form was submitted from an internal page (with
attention to ports if possible
will
change how the name/value pairs appear.
- Original Message -
From: Igor Ilyinsky [EMAIL PROTECTED]
To: CF-Talk [EMAIL PROTECTED]
Sent: Monday, June 23, 2003 12:24 PM
Subject: CFMX Form Submission Hacking.
Does anyone have a quick snippet of code that does a regex match against
;
process
else
die
hth,
Mike
- Original Message -
From: Igor Ilyinsky [EMAIL PROTECTED]
To: CF-Talk [EMAIL PROTECTED]
Sent: Monday, June 23, 2003 12:24 PM
Subject: CFMX Form Submission Hacking.
Does anyone have a quick snippet of code that does a regex match against
I realize this... It will not completely prevent hacking...
but I would like to make sure that if a person is on my form page, they are not able
to save the page, edit some of the hidden form variables, and then submit the page to
my server. I am aware that the referrer can be simulated
PROTECTED]
Sent: Monday, June 23, 2003 1:40 PM
Subject: RE: CFMX Form Submission Hacking.
I realize this... It will not completely prevent hacking...
but I would like to make sure that if a person is on my form page, they
are not able to save the page, edit some of the hidden form variables
:[EMAIL PROTECTED]
Sent: Monday, June 23, 2003 12:51 PM
To: CF-Talk
Subject: Re: CFMX Form Submission Hacking.
Why not just set some kind of variable on the form page itself, such as
session.isOnMyServer
and then on the processing page, check for the existence of that variable...
Would
PROTECTED]
To: CF-Talk [EMAIL PROTECTED]
Sent: Monday, June 23, 2003 2:24 PM
Subject: RE: CFMX Form Submission Hacking.
I'm not sure how that would work Mike... If I set the session variable,
and the user comes back (within the session timeout timeframe) wouldn't the
session variable persist? It's
; session.notahacker is still 1 --
What was solved?
-Igor
-Original Message-
From: Michael T. Tangorre [mailto:[EMAIL PROTECTED]
Sent: Monday, June 23, 2003 1:38 PM
To: CF-Talk
Subject: Re: CFMX Form Submission Hacking.
Form Page - set the session variable equal to 1
Processing Page - check
Hacking.
Still not sure how what you're saying works. Let me give you a scenario.
User clicks checkout on the e-commerce app. from his shopping cart.
-- request gets sent to form page; session.notahacker = 1 --
The page comes up with a request for his CC info in a form.
The same form has a hidden
-Original Message-
From: Michael T. Tangorre [mailto:[EMAIL PROTECTED]
Sent: Monday, June 23, 2003 1:38 PM
To: CF-Talk
Subject: Re: CFMX Form Submission Hacking.
Form Page - set the session variable equal to 1
Processing Page - check to see if the session variable equals 1
-Original Message-
From: Igor Ilyinsky [mailto:[EMAIL PROTECTED]
Sent: Monday, June 23, 2003 11:47 AM
To: CF-Talk
Subject: RE: CFMX Form Submission Hacking.
Still not sure how what you're saying works. Let me give you a scenario.
User clicks checkout on the e-commerce app. from
.
Apparently not,
Igor
-Original Message-
From: Matt Robertson [mailto:[EMAIL PROTECTED]
Sent: Monday, June 23, 2003 2:06 PM
To: CF-Talk
Subject: RE: CFMX Form Submission Hacking.
You're right. That will not protect you, but the problem isn't
Michael's suggestion; its your application design
I have opted to circumvent unnecessary processing by
passing these elements through form fields, which improve my
application design and performance. My only issue is making
sure that the submission in authentic, which is not that hard
to do, only I was hoping that someone here was clever
In addition - can't you use some domain variables to check
that the refererrer is coming from your domain online. If
a user submits from his or her desktop it certainly won't
match your domain. Or path info stuff... you know where
your form is - you can verify the path maybe
That's what
Still not sure how what you're saying works. Let me give you
a scenario.
User clicks checkout on the e-commerce app. from his shopping cart.
-- request gets sent to form page; session.notahacker = 1 --
The page comes up with a request for his CC info in a form.
The same form has a hidden
Message-
From: Dave Watts [mailto:[EMAIL PROTECTED]
Sent: Monday, June 23, 2003 12:47 PM
To: CF-Talk
Subject: RE: CFMX Form Submission Hacking.
I have opted to circumvent unnecessary processing by
passing these elements through form fields, which improve my
application design and performance
-
From: Matt Robertson [mailto:[EMAIL PROTECTED]
Sent: Monday, June 23, 2003 2:06 PM
To: CF-Talk
Subject: RE: CFMX Form Submission Hacking.
You're right. That will not protect you, but the problem isn't
Michael's suggestion; its your application design.
Hidden form vars are just flat out
Couldn't you also put in some referrer security that looks
for the server's IP or hostname so people can't post it
from other sites/servers?
Your web server can't guarantee the reliability of that information - all it
really knows is that it received a request from a specific IP address.
Submission Hacking.
I have opted to circumvent unnecessary processing by
passing these elements through form fields, which improve my
application design and performance. My only issue is making
sure that the submission in authentic, which is not that hard
to do, only I was hoping that someone
Submission Hacking.
I do what another poster mentioned: I pass nothing but the session ID and recalculate
the cart based on the info in the db.
I'm of course unfamiliar with the specifics of your app, but the only thing I think
has been done before with regard to passing prices via form vars is hack
I don't like overloading the client scope with unnecessary information either.
Where security is concerned, this is not unnecessary.
It must seem like everybody is piling on criticism and not listening to what you're
asking in the first place, but what you've chosen to do is almost worst-case
I have opted to circumvent unnecessary processing by
passing these elements through form fields, which improve my
application design and performance. My only issue is making
sure that the submission in authentic, which is not that hard
to do, only I was hoping that someone here
It's secure enough to the point where only somebody who can
rewrite the raw HTTP header to look like the one on my
servers, is able to get a hack through. This is hard enough
to do, and enough of a rare case, that if they did that, I'm
sure the admins would eventually (if not immediately)
Form Submission Hacking.
It's secure enough to the point where only somebody who can
rewrite the raw HTTP header to look like the one on my
servers, is able to get a hack through. This is hard enough
to do, and enough of a rare case, that if they did that, I'm
sure the admins would
]
Sent: Monday, June 23, 2003 1:31 PM
To: CF-Talk
Subject: RE: CFMX Form Submission Hacking.
It's secure enough to the point where only somebody who can
rewrite the raw HTTP header to look like the one on my
servers, is able to get a hack through. This is hard enough
to do, and enough
: Ben Schwemlein [mailto:[EMAIL PROTECTED]
Sent: Sunday, March 09, 2003 8:45 PM
To: CF-Talk
Subject: Hacking Client Variables?
Can anyone suggest a way to hack a query that has WHERE userid =
'#CLIENT.userid#' in CF 5 and/or MX? Another developer has an
application
that has sensitive customer
Can anyone suggest a way to hack a query that has WHERE userid =
#CLIENT.userid# in CF 5 and/or MX? Another developer has an application
that has sensitive customer information that is encrypted at the database
level, but not at the ColdFusion level. I think this is not secure, but I
parameters, which simply act as a mapping for CF to know which
client/session vars to use for their requests.
-Justin Scott
- Original Message -
From: Ben Schwemlein [EMAIL PROTECTED]
To: CF-Talk [EMAIL PROTECTED]
Sent: Sunday, March 09, 2003 11:44 PM
Subject: Hacking Client Variables
granted that that is true. however doesn't CF or any other programming
language do the same thing. and if the way your getting at
the data is by
using form and url parameter, then it's very easy for me to
do from the
website and not even bother to try hack the database. using
client
In a few months nobody is using CF 4.5 anyway.
Really? And you can guarantee this? We have people on this list still
using CF4, that's 3 generations old (since CFMX is out now) - people
stick with software the know works...
Not everybody can afford to/wants to upgrade to the latest software -
, 2002 3:21 PM
To: CF-Talk
Subject: RE: Hacking a shared SQL server
Also if
you're the type of person that likes to use integers for primary keys
instead of unique identifiers, then I can see you getting at anything in the
database from a stored procedure.
woah woahcall me dumb here
-Original Message-
From: Brandon Harper [mailto:[EMAIL PROTECTED]]
Sent: Friday, June 07, 2002 2:38 AM
To: CF-Talk
Subject: RE: Hacking a shared SQL server
I was just thinking about this issue today myself since I'm currently
working on something that involves the privacy issues
Philip Arnold - ASP wrote:
In a few months nobody is using CF 4.5 anyway.
Really? And you can guarantee this? We have people on this list still
using CF4, that's 3 generations old (since CFMX is out now) - people
stick with software the know works...
Not everybody can afford to/wants to
But are they running a shared host with sandbox security? Or do they
only run code they consider trusted?
Although there are probably thousands of systems around running CF
4.5.x, I would be surprised if there were more than a couple of dozen
running shared hosting services, and less then
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Friday, June 07, 2002 9:03 AM
To: CF-Talk
Subject: RE: Hacking a shared SQL server
I personally always use uniqueidentifiers for primary keys, it's just a
perference of mine. are they harder to work
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Friday, June 07, 2002 9:03 AM
To: CF-Talk
Subject: RE: Hacking a shared SQL server
I personally always use uniqueidentifiers for primary keys, it's just a
perference of mine. are they harder to work
hey guys, i just thought about this, and it's making me feel uneasy
about using shared SQL server.
ok, i did a test hack on a live server.
As you know in SQL Enterprise, you're able to see the database names
of other people sharing the SQL server. and by looking at the names
you can
]]
Sent: Thursday, June 06, 2002 10:11 AM
To: CF-Talk
Subject: Hacking a shared SQL server
hey guys, i just thought about this, and it's making me feel uneasy
about using shared SQL server.
ok, i did a test hack on a live server.
As you know in SQL Enterprise, you're able to see the database
- Original Message -
From: [EMAIL PROTECTED]
--snip--
And to prevent that would be to never us an obvious DSN. name it
something like Hys72hs!
--snip-
Seems like a good idea - assuming you use a #request.DSN# or
#application.DSN# variable, you only have to
I have a tool that will read the registry and pull the
datasources on the machine the tool is on.
The tool will check for the registry and if the
registry tag is disabled it will give you a text box to
manually type in a datasource.
Then the tool will act like a simplified version of
PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Thursday, June 06, 2002 1:11 PM
To: CF-Talk
Subject: Hacking a shared SQL server
hey guys, i just thought about this, and it's making me feel uneasy
about using shared SQL server.
ok, i did a test hack on a live server.
As you know in SQL Enterprise
in Deerfield beach at 7:30pm. I will go into detail about this tonight.
Anthony Petruzzi
Webmaster
954-321-4703
[EMAIL PROTECTED]
http://www.sheriff.org
-Original Message-
From: Ken Wilson [mailto:[EMAIL PROTECTED]]
Sent: Thursday, June 06, 2002 1:33 PM
To: CF-Talk
Subject: RE: Hacking a shared SQL
[EMAIL PROTECTED] wrote:
As you know in SQL Enterprise, you're able to see the database names
of other people sharing the SQL server. and by looking at the names
you can probably guess what they named their DSN. I got lucky, and
nabbed one. I pulled out the table names from
: Thursday, June 06, 2002 12:50 PM
To: CF-Talk
Subject: RE: Hacking a shared SQL server
that's because you didn't secure your database like your suppose to. I'm
actually doing a presentation tonight for our CFUG about securing your
SQL
database.
In a nut shell what you should do is create a user
it
for a year now too. I haven't been able to do so yet.
Anthony Petruzzi
Webmaster
954-321-4703
[EMAIL PROTECTED]
http://www.sheriff.org
-Original Message-
From: Cravens, Billy [mailto:[EMAIL PROTECTED]]
Sent: Thursday, June 06, 2002 2:02 PM
To: CF-Talk
Subject: RE: Hacking a shared SQL
hey guys, i just thought about this, and it's making me
feel uneasy about using shared SQL server.
You should feel that way about using a shared anything. I agree 100% with
Matt on this. Hey, wait, what's that two-headed goat doing here?
ok, i did a test hack on a live server.
You'll want
you're wrong on this billy. by doing it this way, the only
thin a person can execute is the stored procedures that you
allow them to. they will not be able to use cfquery to do
queries directly against the database. i have been doing
this for around a year now, and have been trying to
Tony is right. If permissions are set properly on SQL, no matter what you
put in cf admin, it won't access sql.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Thursday, June 06, 2002 2:09 PM
To: CF-Talk
Subject: RE: Hacking a shared SQL server
you're wrong
NOT trying to start a fight here. I just don't understand why I would
care about someone hacking or stealing passwords to a DSN that is totally
locked down. Plus I don't get what you mean when you said even being able
to call those stored procedures is a serious security issue, as I'm sure
you're aware
: RE: Hacking a shared SQL server
well them let me ask you this. if i locked down my database to the
point
where they can only access the stored procedures that I want them to,
then
what do I care if they get ahold of the password to the DSN. They
would
only
be able to do anything that I didn't
elaborate
Anthony Petruzzi
Webmaster
954-321-4703
[EMAIL PROTECTED]
http://www.sheriff.org
-Original Message-
From: Matt Liotta [mailto:[EMAIL PROTECTED]]
Sent: Thursday, June 06, 2002 2:47 PM
To: CF-Talk
Subject: RE: Hacking a shared SQL server
If I only have access to run your
experience with Adv. Security is extremely limited)
---
Billy Cravens
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Thursday, June 06, 2002 1:09 PM
To: CF-Talk
Subject: RE: Hacking a shared SQL server
you're wrong on this billy. by doing it this way, the only
doesn't stop me from accessing your data.
-Matt
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Thursday, June 06, 2002 11:52 AM
To: CF-Talk
Subject: RE: Hacking a shared SQL server
elaborate
Anthony Petruzzi
Webmaster
954-321-4703
[EMAIL PROTECTED
.
I'm NOT trying to start a fight here. I just don't understand
why I would care about someone hacking or stealing passwords
to a DSN that is totally locked down. Plus I don't get what
you mean when you said even being able to call those stored
procedures is a serious security issue, as I'm
[EMAIL PROTECTED]
http://www.sheriff.org
-Original Message-
From: Matt Liotta [mailto:[EMAIL PROTECTED]]
Sent: Thursday, June 06, 2002 3:00 PM
To: CF-Talk
Subject: RE: Hacking a shared SQL server
Suppose you stored all your customer information in your database. Your
application only used
Ok, but you're changing the subject.
-Matt
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Thursday, June 06, 2002 12:09 PM
To: CF-Talk
Subject: RE: Hacking a shared SQL server
granted that that is true. however doesn't CF or any other programming
, June 06, 2002 3:09 PM
To: CF-Talk
Subject: RE: Hacking a shared SQL server
granted that that is true. however doesn't CF or any other programming
language do the same thing. and if the way your getting at the data is by
using form and url parameter, then it's very easy for me to do from
damn good example david, damn good. I stand corrected.
Anthony Petruzzi
Webmaster
954-321-4703
[EMAIL PROTECTED]
http://www.sheriff.org
-Original Message-
From: Dave Watts [mailto:[EMAIL PROTECTED]]
Sent: Thursday, June 06, 2002 3:13 PM
To: CF-Talk
Subject: RE: Hacking a shared SQL
-Talk
Subject: RE: Hacking a shared SQL server
Also if
you're the type of person that likes to use integers for primary keys
instead of unique identifiers, then I can see you getting at anything
in
the
database from a stored procedure.
woah woahcall me dumb here, but by unique
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Thursday, June 06, 2002 2:09 PM
To: CF-Talk
Subject: RE: Hacking a shared SQL server
granted that that is true. however doesn't CF or any other programming
language do the same thing. and if the way your getting
Actually there is nothing wrong with using an integer for a primary key.
The trick is to make sure they aren't in sequence, so that people can't
guess other keys.
Matt,
Do you have any methods for creating non-sequenced integer primary keys
that aren't a performance hit? I can think
so how do you prevent that from happening?
-Original Message-
From: Matt Liotta [mailto:[EMAIL PROTECTED]]
Sent: Thursday, June 06, 2002 3:27 PM
To: CF-Talk
Subject: RE: Hacking a shared SQL server
Actually there is nothing wrong with using an integer for a primary key.
The trick
Most languages don't stored connection information in a
central repository - you have to provide credentials at
code time.
You can do that in CF, of course - there's nothing forcing you to store them
in the datasource settings.
Unless your file system is insecure (ie, everyone can see
Use GUID's?
---
Billy Cravens
-Original Message-
From: Tony Carcieri [mailto:[EMAIL PROTECTED]]
Sent: Thursday, June 06, 2002 2:45 PM
To: CF-Talk
Subject: RE: Hacking a shared SQL server
so how do you prevent that from happening?
-Original Message-
From: Matt Liotta [mailto
Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Thursday, June 06, 2002 1:53 PM
To: CF-Talk
Subject: RE: Hacking a shared SQL server
Actually there is nothing wrong with using an integer for a primary key.
The trick is to make sure they aren't in sequence, so that people
credentials are stored in CF Admin, is insecure without
even trying.
---
Billy Cravens
-Original Message-
From: Dave Watts [mailto:[EMAIL PROTECTED]]
Sent: Thursday, June 06, 2002 2:55 PM
To: CF-Talk
Subject: RE: Hacking a shared SQL server
Most languages don't stored connection
PROTECTED]]
Sent: Thursday, June 06, 2002 12:53 PM
To: CF-Talk
Subject: RE: Hacking a shared SQL server
Actually there is nothing wrong with using an integer for a primary
key.
The trick is to make sure they aren't in sequence, so that people
can't
guess other keys.
Matt,
Do you have
Message-
From: Tony Carcieri [mailto:[EMAIL PROTECTED]]
Sent: Thursday, June 06, 2002 12:45 PM
To: CF-Talk
Subject: RE: Hacking a shared SQL server
so how do you prevent that from happening?
-Original Message-
From: Matt Liotta [mailto:[EMAIL PROTECTED]]
Sent: Thursday, June
While a GUID is a string, conceptually you can do the same thing with a
long long.
-Matt
-Original Message-
From: Shawn Grover [mailto:[EMAIL PROTECTED]]
Sent: Thursday, June 06, 2002 1:02 PM
To: CF-Talk
Subject: RE: Hacking a shared SQL server
I've seen a number of references
Who needs to hack a file system on a shared host? Just use cfmail to
email other people's files to you.
-Matt
-Original Message-
From: Cravens, Billy [mailto:[EMAIL PROTECTED]]
Sent: Thursday, June 06, 2002 1:01 PM
To: CF-Talk
Subject: RE: Hacking a shared SQL server
True - I
Dave Watts wrote:
Well, here's where it becomes tricky. I'll go back to my prior example, with
Matt and me sharing a server. Each has set permissions that keep the other
out, of course - Matt doesn't trust me as far as he can throw me, and I've
been putting on weight. However, we can both
Like any database question though, the best answer is to ask your DBA.
Unless you are the DBA... then you're just S.O.L. g
Ben Johnson
Hostworks, Inc.
__
Your ad could be here. Monies from ads go to support these lists and
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Thursday, June 06, 2002 1:53 PM
To: CF-Talk
Subject: RE: Hacking a shared SQL server
Actually there is nothing wrong with using an integer for a
primary key.
The trick is to make sure they aren't in sequence, so
hehe... see - now that is kinda mean
-Original Message-
From: Matt Liotta [mailto:[EMAIL PROTECTED]]
Sent: Thursday, June 06, 2002 3:08 PM
To: CF-Talk
Subject: RE: Hacking a shared SQL server
Who needs to hack a file system on a shared host? Just use cfmail to
email other people's
Who needs to hack a file system on a shared host? Just
use cfmail to email other people's files to you.
hehe... see - now that is kinda mean
Why, because it might crash the server and leave the spool directory full of
zero-byte files or something?
Dave Watts, CTO, Fig Leaf Software
quite well.
-Matt
-Original Message-
From: Jochem van Dieten [mailto:[EMAIL PROTECTED]]
Sent: Thursday, June 06, 2002 2:01 PM
To: CF-Talk
Subject: Re: Hacking a shared SQL server
Matt Liotta wrote:
Who needs to hack a file system on a shared host? Just use cfmail
to
email other
Coming out of left field here as I haven't read everything but what about in your code
getting a random number, checking to make sure its not in your table then insert it.
Just run a loop.
[EMAIL PROTECTED] 06/06/02 03:52PM
Actually there is nothing wrong with using an integer for a
: Michael Ross [mailto:[EMAIL PROTECTED]]
Sent: Thursday, June 06, 2002 3:23 PM
To: CF-Talk
Subject: RE: Hacking a shared SQL server
Coming out of left field here as I haven't read everything but what about in
your code getting a random number, checking to make sure its not in your
table then insert
-Talk
Subject: RE: Hacking a shared SQL server
Coming out of left field here as I haven't read everything but what
about
in your code getting a random number, checking to make sure its not in
your table then insert it. Just run a loop.
[EMAIL PROTECTED] 06/06/02 03:52PM
Actually
The only upper limit for any random number is how many bits long it is.
Of course this limit is the same for a sequential primary key.
-Matt
-Original Message-
From: Shawn Grover [mailto:[EMAIL PROTECTED]]
Sent: Thursday, June 06, 2002 2:32 PM
To: CF-Talk
Subject: RE: Hacking
Coming out of left field here as I haven't read
everything but what about in your code getting a
random number, checking to make sure its not in
your table then insert it. Just run a loop.
That does work, however, it is also a performance hit. The performance hit
dramatically increases as
topic... grins
Shawn Grover
-Original Message-
From: Matt Liotta [mailto:[EMAIL PROTECTED]]
Sent: Thursday, June 06, 2002 3:35 PM
To: CF-Talk
Subject: RE: Hacking a shared SQL server
The only upper limit for any random number is how many bits long it is.
Of course this limit is the same
-Original Message-
From: Michael Ross [mailto:[EMAIL PROTECTED]]
Sent: Thursday, June 06, 2002 5:23 PM
To: CF-Talk
Subject: RE: Hacking a shared SQL server
Coming out of left field here as I haven't read everything but
what about in your code getting a random number, checking
to convince some people to do this.
I can even have an FBI agent supervise me while I
do it as they love free training.
Free training in hacking my server? Why would they want that? In a few
months nobody is using CF 4.5 anyway.
Of course you're free to just keep thinking shared hosting
I'm sure someone can give me a good example of why to not use sequential
primary keys, however. So I am ready to learn why this might not be as
secure as using a hash or GUID, given my methodology and security
practices
for handline this data, of course. Just because someone can look at
- a copy of the waiver
No problem
- credentials/testimonials that you are white hat
Can't do that as I am not white hat. You think I work with the FBI by
choice?
- an assesment of the risk you disturb normal operation of the machine
Also no problem
Free training in hacking my server
This was one from CF-Community about a month and 1/2 ago... It's a website
with hacking challenges to complete. Quite addictive once you get into
it. I made it to level 6 and was stumped...
www.try2hack.nl -- don't let it eat all your time as it will...
Please don't perpetuate this thread
Yes but this was a simple contrived example at how a
social engineering example would work. In reality it
would be a little more complex but social engineering
is a way of hacking that combines social interaction
with technology to form a 'best of breed' sort of system
infiltration.
It is all
1 - 100 of 139 matches
Mail list logo
