On Fri, Jun 8, 2012 at 12:37 PM, Ethan Rosenberg eth...@earthlink.net wrote:
Is it possible to have a meeting of the minds to come up with (an)
appropriate method(s)?
Minds, meet prepared statements :)
Adam
--
Nephtali: A simple, flexible, fast, and security-focused PHP framework
-Original Message-
From: Adam Richardson [mailto:simples...@gmail.com]
Sent: Friday, June 08, 2012 11:50 AM
To: PHP-General
Subject: Re: [PHP] SQL Injection
On Fri, Jun 8, 2012 at 12:37 PM, Ethan Rosenberg eth...@earthlink.net
wrote:
Is it possible to have a meeting of the minds to come
Is it possible to have a meeting of the minds to come up with (an)
appropriate method(s)?
Minds, meet prepared statements :)
PDO is the way to go :D
Not to refute the above advice one bit (not to mention oppose the arguments
against escaping in general) ... but just curious - can
On 06/08/2012 10:31 AM, Govinda wrote:
Is it possible to have a meeting of the minds to come up with (an)
appropriate method(s)?
Minds, meet prepared statements :)
PDO is the way to go :D
Not to refute the above advice one bit (not to mention oppose the arguments
against escaping in
Jim Lucas wrote:
Not to refute the above advice one bit (not to mention oppose the arguments
against escaping in general) ... but just curious - can anyone demo a hack
that effectively injects past mysqli_real_escape_string(), while using utf-8
? It may just be a matter of time (or already?)
Ah, but what if I use sqlite or postgres?
Or Firebird ;)
good point.
IMHO, the discussion needs to be a the best way to prevent SQL injection
across
all possible DB types. Not just mysql.
The main thing to avoid is building queries from elements that are directly
loaded from the
Govinda govinda.webdnat...@gmail.com wrote:
Ah, but what if I use sqlite or postgres?
Or Firebird ;)
good point.
IMHO, the discussion needs to be a the best way to prevent SQL
injection across
all possible DB types. Not just mysql.
The main thing to avoid is building queries from
I think you can happily sanitise data where it makes sense, and use bound
parameters elsewise. So when you expect a number, its easy to check for and
force a sensible default. Likewise for things like dates, or names of
articles (probably a popular need with a CMS) you can check and enforce
This is an interesting conversation, so I'm glad it got brought up,but I
find myself curious: Are you actually trying to avoid PDO, or just trying
to learn how the security actually works?
Well, It's a learning process. my point is this... If I can make it
safe and sound without the PDO,
Hi there!
2009/5/6 Igor Escobar titiolin...@gmail.com
Hi folks,
Someone know how i can improve this function to protect my envairounment
vars of sql injection attacks.
that is the function i use to do this, but, some people think is not enough:
* @uses $_REQUEST=
On Wed, May 6, 2009 at 12:06 PM, Bruno Fajardo bsfaja...@gmail.com wrote:
Hi there!
2009/5/6 Igor Escobar titiolin...@gmail.com
Hi folks,
Someone know how i can improve this function to protect my envairounment
vars of sql injection attacks.
that is the function i use to do this, but,
I know that use the mysql_real_escape_string to do de job is better but you
should consider that the this function don't have any access to the data
base, to objective of this function is sanitize the string.
And please, see my second answer, i make some updates in the function that
possibly is
mysql_escape_string can be used instead. You just lose the ability to
have it match coallation. I still think there should be the
mysql_escape_string or real one and allow it to pass the coallation
without a database handle -or- just make a unicode/utf8 one and be
done with it.
On May 6,
YOU can write (') characters in the database.. that fine..
mysql_real_escape_string avoid injections doing that: escaping characters
then when you put in a form
abc'''def
the query will be
INSERT . (name.) VALUES ( 'abc\'\'\'def'
each ' = \'
for me the steps are right
saludos
Peter Lauri wrote:
Thank you all for your replies; it has been interesting to read. I am just
waiting for the webmaster to reply to me with his thoughts.
My intentions for this were to help, not to break, so I do indeed hope that
they will not take legal action for it. A friend of mine hoped
On 02/08/06, Jochem Maas [EMAIL PROTECTED] wrote:
Russell Jones wrote:
In real life terms, if you walked into the store and saw that the cash
register was slightly broken and slightly opened, and reached in and pulled
out a dollar to show the cashier what was wrong, you would not get in
On Thu, August 3, 2006 2:32 am, Peter Lauri wrote:
Is there anyone in this group that has a simple script to check for
SQL
injection attacks?
http://php.net/mysql_real_escape_string
should cover this, no?
Another option is to use a query mechanism based on prepared
statements rather than raw
This is a good question and it, by and large, has not been considered.
In this particular instance, their programming is not protected by any kind
of encryption laws that would prevent decryption (such as developing and
deploying the decryption of Adobe Ebooks format).
Furthermore, because you
Russell Jones wrote:
This is a good question and it, by and large, has not been considered.
In this particular instance, their programming is not protected by any kind
of encryption laws that would prevent decryption (such as developing and
deploying the decryption of Adobe Ebooks format).
Peter Lauri wrote:
Hi all,
I saw some strange error messages from a site when I was surfing it, and it
was in form of SQL. I did some testing of the security of the SQL injection
protection of that site, and it showed it was not that protected against SQL
injections. To show this to them, I
Thank you all for your replies; it has been interesting to read. I am just
waiting for the webmaster to reply to me with his thoughts.
My intentions for this were to help, not to break, so I do indeed hope that
they will not take legal action for it. A friend of mine hoped that they
would use the
Hello Mark, Where can I find these articles that you talk? do you have a URL
for those articles?
Thank you :)
=
?Acaso se olvidara la mujer de su bebe, y dejara de compadecerse del hijo
de su vientre? Aunque ellas se olviden, yo no me olvidare de ti
Isa 40:27
=
Atte Pedro Iran
On Wed, 3 Nov 2004 19:02:22 -0800 (PST), Chris Shiflett
[EMAIL PROTECTED] wrote:
There is a lot more. I highlight some of the things I think are of
principal concern for PHP developers in something I call the PHP Security
Workbook:
http://shiflett.org/php-security.pdf
That doesn't cover
--- Jordi Canals [EMAIL PROTECTED] wrote:
I highlight some of the things I think are of principal concern
for PHP developers in something I call the PHP Security Workbook:
http://shiflett.org/php-security.pdf
That doesn't cover everything, of course, but it covers those
things I
Hi,
look for escapeshellcmd().
It is another good function to minimize the security risks.
http://in2.php.net/escapeshellcmd
Zaeeef ahmed
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Thursday, November 04, 2004 3:55 AM
To: [EMAIL PROTECTED]
Subject:
--- [EMAIL PROTECTED] wrote:
I read now quite a lot of articles about SQL-Injection,
XSS, and session hijacking in a hopefully appropriate way.
As I understand the function addslashes(), quote_meta(),
and mysql_real_escape_string() are to avoid SQL Injection
The database-specific escaping
On Tue, 23 Mar 2004 12:05:17 -0800, Pablo Gosse wrote:
I think you have misunderstod the concepts of making queries based on
user input. It is not the users who should create the query, all to
should do is provide the input to narrow down the queries.
I have not misunderstood the concepts
snip
The idea is exactly not to do any queries dynamically generated based
on user input! In the rare cases where this is needed you should not
allow any unparsed input.
/snip
A RARE case, in the world of web applications??? Hardly!
I agree that in an optimal situation queries will not
--- Michael Rasmussen [EMAIL PROTECTED] wrote:
The idea is exactly not to do any queries dynamically generated based
on user input!
This argument still makes no sense to me. Originally, you stated that a
better option to filtering and escaping data was to use a prepared
statement. Some of us
On Tue, 23 Mar 2004 08:25:32 -0800, Pablo Gosse wrote:
A RARE case, in the world of web applications??? Hardly!
I agree that in an optimal situation queries will not be based on user
input, but in the world of the web this is a pipe dream. In 99.99% of the
cases there will be some
On Tue, 23 Mar 2004 09:27:29 -0800, Chris Shiflett wrote:
This argument still makes no sense to me. Originally, you stated that a
better option to filtering and escaping data was to use a prepared
statement. Some of us have decided that you are referring to stored
procedures.
You still
--- Michael Rasmussen [EMAIL PROTECTED] wrote:
I think you have misunderstod the concepts of making queries based
on user input. It is not the users who should create the query, all
to should do is provide the input to narrow down the queries.
To be honest, I think Pablo understands the
snip
PG A RARE case, in the world of web applications??? Hardly!
PG
PG I agree that in an optimal situation queries will not be based on
PG user input, but in the world of the web this is a pipe dream. In
PG 99.99% of the cases there will be some dynamic element to a query.
PG The only
On Sunday 21 March 2004 06:39 pm, Chris Shiflett wrote:
--- Michael Rasmussen [EMAIL PROTECTED] wrote:
To be clear: make sure the data that the user submitted only
contains the characters you think are valid (don't bother trying
to guess malicious characters - you're sure to miss one)
On 21 Mar 2004 Chris Shiflett wrote:
I would never argue that something is an absolute defense, but I would
characterize my recommendation as a best practice.
Fair enough.
I agree with you that checking for valid characters is safer than
checking for malicious characters, but even the
On Sun, 21 Mar 2004 18:39:39 -0800, Chris Shiflett wrote:
Can you explain that (and defend it)?
The reason is security. A prepared statement cannot comprimize the
security of our database because all sql-statements are precompiled in the
DBMS. An example using pear:
$res =
snip
The reason is security. A prepared statement cannot comprimize the
security of our database because all sql-statements are precompiled
in the DBMS. An example using pear:
$res = DB:connect('mysql://someuser:[EMAIL PROTECTED]/thedb');
$sth = $res-prepare('select * from sometable
On Mon, 22 Mar 2004 14:36:44 -0800, Pablo Gosse wrote:
Huh? How does this accommodate for a dynamically generated query which is
based upon user input?
Have you read my arguments? A prepared statement cannot be dynamically
generated!
It is validated and its type set before it is
On 23 Mar 2004 Michael Rasmussen wrote:
The idea is exactly not to do any queries dynamically generated based on
user input! In the rare cases where this is needed you should not
allow any unparsed input.
There are some applications for which queries based on typed user input
are rare. But
--- Ali Ashrafzadeh [EMAIL PROTECTED] wrote:
I'm looking for a function To check SQL Injection in Mysql RDBMS
please tell me if anyone know good function or solution
In my opinion, this is the wrong approach.
SQL injection vulnerabilities exist when you use data that the user gave
you to
On Sun, 21 Mar 2004 13:49:22 -0800, Chris Shiflett wrote:
To be clear: make sure the data that the user submitted only contains the
characters you think are valid (don't bother trying to guess malicious
characters - you're sure to miss one) and is a valid length. Once you've
done this, and
--- Michael Rasmussen [EMAIL PROTECTED] wrote:
To be clear: make sure the data that the user submitted only
contains the characters you think are valid (don't bother trying
to guess malicious characters - you're sure to miss one) and is a
valid length. Once you've done this, and your
On 21 Mar 2004 Chris Shiflett wrote:
SQL injection vulnerabilities exist when you use data that the user gave
you to create your SQL statement. So, anytime that this happens, simply
make absolutely sure that the data you are using from the user fits a very
specific format that you are
--- [EMAIL PROTECTED] wrote:
Recently I've been in the middle of trying to build defenses against
SQL injection on a site I'm working on (proactively, we haven't had a
problem). While this principle seems exactly right, I find it's not as
easy to implement as it sounds, and I'd argue that
Hi i read many thing on sql injection but i just cant sumarize all the
information.
Most site (PHPadvisory.com, phpsecure.info, other found on google) dont
talk to mutch on how to prevent SQL injection.
One of the things I tend to do to limit any damage is tell the backend SQL
server to not
Yann Larrivee wrote:
Hi i read many thing on sql injection but i just cant sumarize all the
information.
Most site (PHPadvisory.com, phpsecure.info, other found on google) dont
talk to mutch on how to prevent SQL injection.
At some place, they mentionned having a badword list, but really in a
On Mon, 23 Jun 2003 08:59:56 +0300, you wrote:
Is there any way, doc, article, example, idea, suggestion to how to
prevent sql injection on php sites...
It's really not that hard to do.
Rule 1: Never trust the client
This means validating all data that comes from the client - make sure that
Hi,
Is there any way, doc, article, example, idea, suggestion to how to
prevent sql injection on php sites...
http://www.nextgenss.com/papers/advanced_sql_injection.pdf
http://www.nextgenss.com/papers/more_advanced_sql_injection.pdf
Kirk
--
PHP General Mailing List (http://www.php.net/)
Yeah, I'm scared...
Please excuse me but may I say that it seems like you've sent some wrong
info to the wrong mailing list?
I use PHP NOT ASP, I use MySQL or PostgreSQL or Oracle but NOT M$ SQL
Server. And IIS? Of course, some people use it (perhaps) because of some
unavoidable
I didn't see that, what a waste of paper
Randy
- Original Message -
From: Edwin @ [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Friday, August 16, 2002 1:14 PM
Subject: Re: [PHP] SQL Injection/Data Balidation
Yeah, I'm scared...
Please excuse me but may I
Actually, I DID read the articles before I replied.
If you read it again, the basic problem is not about any extended SQLServer
functionality--it's about how ASP works AND how the database server was
configured AND how Window$ works.
Sorry, but the attacks mentioned CANNOT be done on any of
Oops! Sorry! I meant to say apostrophe and not single quotes...
And sorry 'bout this additional post...
Regards,
- E
Actually, I DID read the articles before I replied.
If you read it again, the basic problem is not about any extended
SQLServer functionality--it's about how ASP works AND
52 matches
Mail list logo
