m5 old links

m5 old links



Any query using user input, variables that can be overridden, or database
fields including user data, can be potentially dangerous.

Direct injecting of Miva Script tags would not work in compiled Miva Script,
but injecting of queries, or in some cases even functions, may be possible.
Besides it, it also stays to investigate whether the template language
cannot be abused in some way. It is difficult to tell without having the
source code of Miva Merchant, so some deep analysis and heavy duty testing
will be needed to see how it actually works internally.

Ivo Truxa

| http://miva.truxoft.com
| Advanced Miva Merchant modules


-----Original Message-----
From: William Weiland


David Hubbard wrote:
> I don't know
> MivaScript so I'm just theorizing, but maybe by doing something
> like that I'll cause a variable set internal to the script to
> be overridden by what I want it to be, and that's where the
> danger potentially lies.

But accessing the data in Merchant is done with more than select (*)
from s01_Products

For example:
<MvOPENVIEW NAME = "Merchant"
VIEW = "Products"
QUERY = "{'SELECT * FROM ' $ g.Store_Table_Prefix $ 'Products WHERE
id
= ?' }"
FIELDS = "l.product:id">

Isn't Merchant creating a specific way of getting to the data such that
you would need to use the "Mv" commands. Or does somehow having select
(*) from s01_Products floating around allow you to connect outside of
Merchant?

Inquiring minds want to know. So do the hackers.

sql injection possibilties .. bump from m5 old links



changing the subject line here to draw attention on this to Jimmy
hopefully...

There are actually loads of example of how to do sql injection and loads
of example of how to prevent it. passing incoming variable or anything
that write to teh db through a 'cleaner' function can prevent a lot of it.
Just go look at the phpnuke.org forums on sql injection into mysql
databases... it's pretty simple to do. Any jr high kid could figure it out.
It is a concern. If miva hasn't provided a mivascript funtion to 'clean'
the incoming data... then module developer will ahve to make sure they
include a cleaning routing in their modules for any module that shows
variables or takes in data from a form field on the store.

Kelly


Ivo Truxa wrote:

>Any query using user input, variables that can be overridden, or database
>fields including user data, can be potentially dangerous.
>
>Direct injecting of Miva Script tags would not work in compiled Miva Script,
>but injecting of queries, or in some cases even functions, may be possible.
>Besides it, it also stays to investigate whether the template language
>cannot be abused in some way. It is difficult to tell without having the
>source code of Miva Merchant, so some deep analysis and heavy duty testing
>will be needed to see how it actually works internally.
>
>Ivo Truxa
>
>| http://miva.truxoft.com
>| Advanced Miva Merchant modules
>
>
>-----Original Message-----
>From: William Weiland
>
>
>David Hubbard wrote:
>
>
>>I don't know
>>MivaScript so I'm just theorizing, but maybe by doing something
>>like that I'll cause a variable set internal to the script to
>>be overridden by what I want it to be, and that's where the
>>danger potentially lies.
>>
>>
>
>But accessing the data in Merchant is done with more than select (*)
>from s01_Products
>
>For example:
><MvOPENVIEW NAME = "Merchant"
> VIEW = "Products"
> QUERY = "{'SELECT * FROM ' $ g.Store_Table_Prefix $ 'Products WHERE
>id
>= ?' }"
> FIELDS = "l.product:id">
>
>Isn't Merchant creating a specific way of getting to the data such that
>you would need to use the "Mv" commands. Or does somehow having select
>(*) from s01_Products floating around allow you to connect outside of
>Merchant?
>
>Inquiring minds want to know. So do the hackers.
>
>
>