I did - many times before I sent the message. So, explain, please.
From CF: (cfqueryparam) Verifies the data type of a query parameter ...
My example is a text field. The potential inject/bad data language is text. I
just tested it and cfqueryparam did not prevent me from entering potentially
cfqueryparam will not prevent the malicious data from getting entered into
the table. However it does prevent the malicious text from executing as
T-SQL. cfqueryparam does not parse or cleanse data in any way.
Basically it passes the text as a variable to the sql statement. Thus
preventing any
Text input field
Entry is Johnson Johnson's
I store it in a table using cfqueryparam. All is good.
Let's say the hacked entry is Johnson Johnson's;delete * (or something akin
to that - you get the
drift) I use cfqueryparam but it won't catch the hack; it's still just a
string.
Like querying malicious data and using it in another
cfquery without cfqueryparam.
As an extra safety feature, if your application does not use multiSQL
statements at all, and depending on the type of database engine used, you could
also streatly deactivate the multi statement facility.
If
what you really need is a Web Application Firewall which will clean all
form and url params and strip out anything dodgy.
There are plenty of generic web server WAF's, or if you want a CF specific
solution then try FuseGuard.
On Tue, Nov 4, 2014 at 5:26 PM, wrote:
Like querying malicious
cfqueryparam and EncodeForHTML are used to prevent two different types of
attack.
cfqueryparam is for SQL injection attacks, as Byron explained.
EncodeForHTML is used to prevent cross site scripting attacks (it does not
prevent/escape sql injection), which exist when the attacker can execute
Hi Al
Thanks for this. I will pass the info on to the group I am working with.
Rob
On 2 Nov 2014 at 11:16, Al Musella, DPM wrote:
I use paypal.. Couldn't be easier, and they give a discount on the
rates to nonprofits...
however, there is one big problem...
Bad people have been
7 matches
Mail list logo
