On Thu, Feb 16, 2012, at 11:37 AM, Grigore Dolghin wrote:
bending design to use sqlparameters should be read as
doing
it right in the first place.
It has to be said, the use of parameters is pretty well accepted as best
practice as far as I know, and I also agree with not re-inventing the
I gave it a serious thought and I have concluded that is time for me to
move on. It was a nice journey - been subscribed to this list for 10 years
by now, I believe. But everything has an end.
I wish you all happy lives and happy programming.
On Fri, Feb 17, 2012 at 12:24 PM, Alan Bourke
On Fri, Feb 17, 2012, at 01:06 PM, Grigore Dolghin wrote:
I gave it a serious thought and I have concluded that is time for me to
move on. It was a nice journey - been subscribed to this list for 10
years
by now, I believe. But everything has an end.
Cheerio then!
--
Alan Bourke
It has to be said, the use of parameters is pretty well accepted as best
practice as far as I know, and I also agree with not re-inventing the
wheel to sanitise input yourself when you could let the DB backend do
it, and take advantage of all the expertise and design that went into
it.
Since
On Fri, Feb 17, 2012 at 9:03 AM, Ken Dibble krdib...@stny.rr.com wrote:
Yeah, we can let the DB back-end do it, if we're willing to give up most
of the power that dynamic SQL makes available and resort to maintaining
hundreds of static queries or views. (As I understand it, you can't use ?
On Feb 17, 2012, at 10:26 AM, Stephen Russell wrote:
The power of dynamic SQL ?
That is running with scissors.
I still find it incredible that in 2012 there are people who consider
themselves professional developers who downplay security concerns, and who
ignore basic security
My guess is the latter... or just plain stupidity. :(
ls
-Original Message-
From: profoxtech-boun...@leafe.com [mailto:profoxtech-boun...@leafe.com] On
Behalf Of Ed Leafe
Sent: Friday, February 17, 2012 8:40 AM
To: profoxt...@leafe.com
Subject: Re: [NF] Very strong set of issues in Are
On Feb 17, 2012, at 10:48 AM, M Jarvis wrote:
Don't forget laziness or being a cheapskate Diligence is expensive...
Secure programming practices are not expensive. They are just common
sense.
Protecting data and systems from all possible forms of attack is
certainly
On Fri, Feb 17, 2012 at 4:26 PM, Stephen Russell srussell...@gmail.com wrote:
The power of dynamic SQL ?
That is running with scissors.
See The Curse and Blessings of Dynamic SQL
http://www.sommarskog.se/dynamic_sql.html
For what it's worth my C# code for saving a record is 95% the same as
Well yes, I remember your early posts appearing g, but I just noticed
that on the TIOBE Index [V]FP has dropped out of the top 50 - above
NATURAL and MUMPS but below Q and Smalltalk, so I guess we're all on the
slow train to nowhere, or already on another track.
AndyD 8-)₹
On 17/02/2012 11:06,
Surely what some of this discussion showed was that parameters (even
Foxpro ?parms) do not need delimiters, and if a UI is used (a screen or
even the ancient ACCEPT 'prompt' TO parm) then you don't even need to
use delimiters to create the parameters?
AndyD 8-)₹
On 17/02/2012 15:03, Ken Dibble
Some (much?) of the blame must rest with the DBMS suppliers - Oracle
*used* to be a rigorous cast-iron solid system, but in an attempt to
match the new 'user friendly' upstart from ms they broke security and
referential integrity with things like instead-of triggers on updateable
views and
On 2/17/12 8:52 AM, Ed Leafe wrote:
On Feb 17, 2012, at 10:48 AM, M Jarvis wrote:
Don't forget laziness or being a cheapskate Diligence is expensive...
Secure programming practices are not expensive. They are just common
sense.
Protecting data and systems from all possible
On Fri, Feb 17, 2012, at 10:39 AM, Ed Leafe wrote:
I still find it incredible that in 2012 there are people who consider
themselves professional developers who downplay security concerns, and who
ignore basic security practices.
Look at the Playstation Network breaches last year.
On Fri, Feb 17, 2012, at 10:03 AM, Ken Dibble wrote:
Comment characters are easy to strip out. Type-checking is also easy. If
we
could have a universal string delimiter, honestly, wouldn't something
like
that really be preferable to having to write hundreds of static queries,
views or
I still find it incredible that in 2012 there are people who
consider themselves professional developers who downplay security
concerns, and who ignore basic security practices. There are groups of
people with advanced PhDs in computing, networking and cryptography who
do nothing
At 10:03 AM 2/17/2012 -0500, Ken Dibble wrote:
It has to be said, the use of parameters is pretty well accepted as best
practice as far as I know, and I also agree with not re-inventing the
wheel to sanitise input yourself when you could let the DB backend do
it, and take advantage of all the
I will not insist anymore on this subject. You're defending your approach
fiercely and bending design to use sqlparameters should be read as doing
it right in the first place. Anyway, good luck duplicating an already
existing, fail proof, industry proven code. How would you know you found
them
At 04:37 AM 2/16/2012, you wrote:
I will not insist anymore on this subject. You're defending your approach
fiercely and bending design to use sqlparameters should be read as doing
it right in the first place. Anyway, good luck duplicating an already
existing, fail proof, industry proven code. How
On Tue, Feb 14, 2012, at 08:22 PM, Ken Dibble wrote:
You would say, because if you use a different back end with SQL
pass-through then you have a problem.
To which I reply, My application already validates user input and won't
permit any SQL commands that I do not explicitly want to use
Well I thought I'd resolved this to my own satisfation years ago, bit I
decided to re-visit it -
I couldn't find a way to do SQL injection in FoxPro:
CLEAR
CREATE CURSOR users (user C(5), password c(5))
DISPLAY STRUCTURE
CLEAR
INSERT INTO users values('poo', 'bear')
INSERT INTO users
Hi Andy,
yuser = admin
ypass = '
SELECT * FROM users WHERE user = ?yuser AND password = ?ypass
You shouldn't use a single equals :-)
Paul
On Wed, Feb 15, 2012 at 10:05 AM, AndyD jarnd...@gmail.com wrote:
Well I thought I'd resolved this to my own satisfation years ago, bit I
decided to
On Wed, Feb 15, 2012 at 5:19 AM, Ken Dibble krdib...@stny.rr.com wrote:
You are correct. You can enter stuff into a textbox in VFP that cannot be
inserted into a variable in code.
As it turns out, my app's login code actually defends against login input
that contains troublesome characters,
1) sorry about cross posting (that's the trouble with the digest).
2) OK guv it's a fair cop (though I like to think that when accepting
parms from a form I always got them from drop down lists)
3) The plot thickens a bit more - you *can* create a variable of [admin'
] using 'antique' code but
The app errors because the resulting string is missing a double quote.
I have uploaded a new demo, downloadable from
http://www.class-software.eu/sqlparameters2.zip, which demonstrates the
login bypass using your own code.
Username: admin'
pass: any random password.
Also correct.
All of the examples you've shown me so far rely on the ability to inject
characters that break the line. I've just spent a few hours searching this
topic on Google and I can't find a single example that doesn't rely on
injecting characters that break the line. In that case, why would not
On Mon, Feb 13, 2012, at 08:56 PM, Ken Dibble wrote:
You can't concatenate anything containing to a string in VFP. That
surprised me, frankly, but you can't. It won't work; you'll get Command
contains unrecognized phrase/keyword:
Hey, I didn't know that. It's there in the help as well.
El 14/02/12 05:36, Alan Bourke escribió:
On Mon, Feb 13, 2012, at 08:56 PM, Ken Dibble wrote:
You can't concatenate anything containing to a string in VFP. That
surprised me, frankly, but you can't. It won't work; you'll get Command
contains unrecognized phrase/keyword:
Hey, I didn't
On Tue, Feb 14, 2012 at 3:56 AM, Ken Dibble krdib...@stny.rr.com wrote:
Right, which in turn proves that if you use macro substitution to execute
concatenated SQL statements in VFP, you cannot construct a statement that
can damage your data. Which in turn supports my contention that one size
On Tue, Feb 14, 2012 at 1:56 AM, Ken Dibble krdib...@stny.rr.com wrote:
You can't concatenate anything containing to a string in VFP. That
surprised me, frankly, but you can't. It won't work; you'll get Command
contains unrecognized phrase/keyword:
myvar = Select * From Users where username
Finally, someone that understands what the hell I'm talking about.
On Tue, Feb 14, 2012 at 1:17 PM, Paul Hill paulroberth...@gmail.com wrote:
On Tue, Feb 14, 2012 at 1:56 AM, Ken Dibble krdib...@stny.rr.com wrote:
You can't concatenate anything containing to a string in VFP. That
surprised
Well, you can't append two ampersands in a row in a single string:
Fred = Fred +
because the parser thinks you're starting a comment. But I think you
can append them serially, though:
Fred = Fred + +
On Tue, Feb 14, 2012 at 3:36 AM, Alan Bourke alanpbou...@fastmail.fm wrote:
On Mon, Feb
Being bad isn't a bad thing, as long as you are rich and doesn't need
to work OT!
What's the point being a poor, dead, but good programmer? :)
On Sat, Feb 11, 2012 at 1:04 AM, Stephen Russell srussell...@gmail.com wrote:
http://www.yacoset.com/Home/signs-that-you-re-a-bad-programmer/
--
.~.
Right, which in turn proves that if you use macro substitution to execute
concatenated SQL statements in VFP, you cannot construct a statement that
can damage your data. Which in turn supports my contention that one size
does not fit all when it comes to effective secure code--a
On Tue, Feb 14, 2012 at 1:56 AM, Ken Dibble krdib...@stny.rr.com wrote:
You can't concatenate anything containing to a string in VFP. That
surprised me, frankly, but you can't. It won't work; you'll get Command
contains unrecognized phrase/keyword:
myvar = Select * From Users where
Well, you can't append two ampersands in a row in a single string:
Fred = Fred +
because the parser thinks you're starting a comment. But I think you
can append them serially, though:
Fred = Fred + +
Yup, you can.
But you only get one bite at the apple when entering something into a login
I am sorry, you have no idea what you're talking about. I don't know how
you're doing your tests, but in last 10 minutes I have created an example
which can be downloaded from here:
www.class-software.eu/sqlparameters.zip
Username: admin
Password: adminpass
The program will show how many
Thanks Grigore
I have a better understanding of it now.
Kind regards
Andrew Stirling
01250 874580
supp...@calcpay.co.uk
http://www.calcpay.co.uk
HMRC Accredited UK payroll program
On 15/02/2012 01:45, Grigore Dolghin wrote:
I am sorry, you have no idea what you're talking about. I don't know
I am sorry, you have no idea what you're talking about. I don't know how
you're doing your tests, but in last 10 minutes I have created an example
which can be downloaded from here:
www.class-software.eu/sqlparameters.zip
Username: admin
Password: adminpass
The program will show how many
You can't concatenate anything containing to a string in VFP. That
surprised me, frankly, but you can't. It won't work; you'll get Command
contains unrecognized phrase/keyword:
Hey, I didn't know that. It's there in the help as well.
what about using chr(whatever)?
Yes, that works
Ken,
Your code is proving that macrosubstitution cannot execute multiple lines of
code. As long as you execute commands on VFP data AND the literal value does
not implies multiple lines that's ok. As soon as any of the above conditions
is not met something bad will happen if you use
Your code is proving that macrosubstitution cannot execute multiple lines of
code. As long as you execute commands on VFP data AND the literal value does
not implies multiple lines that's ok.
Right, which in turn proves that if you use macro substitution to execute
concatenated SQL statements
On Sat, Feb 11, 2012 at 8:55 PM, Ken Dibble krdib...@stny.rr.com wrote:
Thus a cite from authority that there is nothing wrong with creating
queries by string concatenation as long as you validate the input first.
Well, I suspect this authority hasn't worked in languages that have
as
Actually, it is easy, just don't declare the variables as local in the
place where are they created. The calls for the method that does the save
(even if it's in a different class) will see those variables.
On Mon, Feb 13, 2012 at 2:40 AM, Ken Dibble krdib...@stny.rr.com wrote:
On Sat, Feb 11,
Actually, it is easy, just don't declare the variables as local in the
place where are they created. The calls for the method that does the save
(even if it's in a different class) will see those variables.
Only works in a monolithic app. Won't work in a setting where the values
are populated
Not true. If the variable is delete from table (it's too late here to
compose a real dangerous variable, but you got the idea), passing it as
literal string will delete the records, while passing it as ?varName will
not. Try it.
On Mon, Feb 13, 2012 at 3:06 AM, Ken Dibble krdib...@stny.rr.com
There is no magical extra security conferred by using ?somevariable as
opposed to just mySQLCommand = CommandText + somevariable. ?somevariable is
just a reference to the content of somevariable. If the type of
somevariable is a string, and you don't validate somevariable before it
That 's as much a display of 'look how superb I think I am' on the
writers part as anything else. Who gives a crap about pointers outside
the C/C++ world ?
On Fri, Feb 10, 2012, at 11:04 AM, Stephen Russell wrote:
http://www.yacoset.com/Home/signs-that-you-re-a-bad-programmer/
--
Alan
This is why I never pursued any C programming jobs because I HATED C and I
HATED POINTERS . LOL
From: Alan Bourke alanpbou...@fastmail.fm
To: profox@leafe.com
Sent: Saturday, February 11, 2012 4:27 AM
Subject: Re: [NF] Very strong set of issues in Are You a
/Symptoms/
1. /Difficulty comprehending the difference between objects and classes/
2. /Difficulty implementing design patterns for your program/
3. /Difficulty writing functions with low cohesion/
4. /Incompetence with Regular Expressions/
5. /Lisp is opaque to you/
6. /Cannot
http://www.yacoset.com/Home/signs-that-you-re-a-bad-programmer/
From the above:
5. Constructing SQL queries by string concatenation with **unvalidated**
or unescaped input (emphasis added)
Thus a cite from authority that there is nothing wrong with creating
queries by string concatenation
On Sat, Feb 11, 2012 at 8:55 PM, Ken Dibble krdib...@stny.rr.com wrote:
Thus a cite from authority that there is nothing wrong with creating
queries by string concatenation as long as you validate the input first.
Well, I suspect this authority hasn't worked in languages that have
as elegant a
Ted - thanks for that Comic - I laughed my Arse Off when I read it!
:-)
-K-
On 2/11/2012 9:16 PM, Ted Roche wrote:
On Sat, Feb 11, 2012 at 8:55 PM, Ken Dibblekrdib...@stny.rr.com wrote:
Thus a cite from authority that there is nothing wrong with creating
queries by string concatenation as
On 2/10/2012 12:04 PM, Stephen Russell wrote:
http://www.yacoset.com/Home/signs-that-you-re-a-bad-programmer/
LOL!
Incompetence with Regular Expressions
Lisp is opaque to you
Cannot fathom the Church-Turing Thesis
Well...that's it for me! Method actor here I come! LOL
--
Mike Babcock,
Hey Mike - my favorite parts:
Signs that you shouldn't be a programmer
1. Inability to determine the order of program execution
Symptoms
a = 5
b = 10
a = b
print a
You look at the code above and aren't sure what number gets printed
out at the end
3. Collyer Brothers syndrome
Symptoms
Any time I cut chunks of code out of my system, I comment it out instead of
deleting it. Anytime I remove a button from a screen, I make it invisible
instead of deleting it. LOL
From: Kurt Wendt kurtwe...@waitex.com
To: profox@leafe.com; profoxt...@leafe.com
56 matches
Mail list logo
