> 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 enfo
Govinda 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 elements t
>> 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
> loade
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?) be
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
>> 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 - c
-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
wrote:
> Is it possible to have a "meeting of the minds" to com
On Fri, Jun 8, 2012 at 12:37 PM, Ethan Rosenberg 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
http://nephtaliproject.com
Dear List -
I am aware of a long email trail on this subject, but there does not
seem to be a resolution.
Is it possible to have a "meeting of the minds" to come up with (an)
appropriate method(s)?
Thanks.
Ethan Rosenberg
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe,
>> 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 PD
I understand some ways are better than others in this one, and it
looks like the PDO based implementations shine the most as far as SQL
Injection.
But would not the following be good enough - without implementing a
PDO solution?
1- get the user input
2- for each input, deliberately enforce a data
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,
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 re
On Wed, May 6, 2009 at 12:06 PM, Bruno Fajardo wrote:
> Hi there!
>
> 2009/5/6 Igor Escobar
>>
>> 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 enou
Hi there!
2009/5/6 Igor Escobar
>
> 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= _antiSqlInjection($_REQUEST);
> * @us
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= _antiSqlInjection($_REQUEST);
* @uses $_POST = _antiSqlInjection($_POST);
* @uses $_
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
O
i have implemented a way to avoid sql injection from the php website from
this url
http://in.php.net/mysql_real_escape_string from the "Example #3 A "Best
Practice" query" section of this page
following are the steps i have followed after the form values are submitted
to a php file.
step 1.
if(
Hi Everyone,
I have a application that I am writing for managing addresses on-
line, I will have a fancy login system using sessions to help store
the info, and to provide security for logging in.
What I am wondering now, is if someone is willing to try and do some
sql injection's on my da
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 ra
Hi,
Is there anyone in this group that has a simple script to check for SQL
injection attacks?
In the theory I was thinking about to check $_POST and $_GET if they contain
specific "substrings" that could be used in an attempt. Maybe to loop thru
all set values and see if they contain "DELE
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
the php
> list also shows the web cam at the same time. "I better watch out"...
>
> Best regards,
> Peter Lauri
>
>
>
>
> -Original Message-
> From: Peter Lauri [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, August 02, 2006 11:17 PM
> To: ph
s,
Peter Lauri
-Original Message-
From: Peter Lauri [mailto:[EMAIL PROTECTED]
Sent: Wednesday, August 02, 2006 11:17 PM
To: php-general@lists.php.net
Subject: [PHP] SQL injection
Hi all,
I saw some strange error messages from a site when I was surfing it, and it
was in form of SQL. I
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
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
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 r
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 deleted my own record
--- 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
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'
Pedro Iran Mendez Perez
-Mensaje original-
De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Enviado el: Miercoles, 03 de Noviembre de 2004 04:25 p.m.
Para: [EMAIL PROTECTED]
Asunto: [PHP] SQL-Injection, XSS and Hijacking
Hi,
I read now quite a lot of articles about SQL-Injection,
XSS a
--- [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 escapi
ED]
>Subject: [PHP] SQL-Injection, XSS and Hijacking
>Hi,
>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 S
Hi,
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
e.g. in order to use page_sliding with entered POST data
over for
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 con
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 safeguard
--- 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 co
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 s
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 so
--- 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
> 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.
A RARE case, in the world of web applications??? Hardly!
I agree that in an optimal situation queries will not be base
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. B
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 i
> 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 w
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 = & DB:connect('m
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 t
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 m
--- [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 tha
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 expe
--- 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 y
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,
--- 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 cr
Hi
I'm looking for a function To check SQL Injection in Mysql RDBMS
please tell me if anyone know good function or solution
thank's
> 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
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
prod
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
product description we c
> 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/)
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...
Thanks
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
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 wor
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
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
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 circumstances
Please CC me as I'm on digest:
--
Are there any libraries for data validation available? If one reads
papers like these:
http://www.nextgenss.com/papers/advanced_sql_injection.pdf
http://www.nextgenss.com/papers/more_advanced_sql_injection.pdf
It beco
64 matches
Mail list logo
