Announcement

Collapse
No announcement yet.

m5 old links

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    #31
    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.



    Comment


      #32
      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.
      >
      >
      >

      Comment

      Working...
      X