1

私は現在、すでに変更されたバージョンのmagento（v 1.6.1）に取り組んでいます。以前の開発者はアプリ/コア自体を変更しましたが、1.7にアップグレードするとどうなりますか？元のアプリ/コアを復元しますよね？（すべてのmodをapp / localの下に配置する必要があることを知っているため）

次に、eコマースでdiffを実行し、1.6.1のクリーンインストールを実行することで、開発者がこの変更を適用したことに気付きました（「<」でマークされた行は元のコンテンツであり、「>」は編集されたコンテンツでした）

diff app/code/core/Mage/Checkout/controllers/CartController.php
169c169,170
<                 $params['qty'] = $filter->filter($params['qty']);
---
>                 #$params['qty'] = $filter->filter($params['qty']);
>                 $params['qty'] = $params['qty'];
311c312,313
<                 $params['qty'] = $filter->filter($params['qty']);
---
>                 #$params['qty'] = $filter->filter($params['qty']);
>                 $params['qty'] = $params['qty'];
383c385,386
<                         $cartData[$index]['qty'] = $filter->filter(trim($data['qty']));
---
>                         //$cartData[$index]['qty'] = $filter->filter(trim($data['qty']));
>                         $cartData[$index]['qty'] = $data['qty'];

お気づきかもしれませんが、$filter->filterとtrimを無効にしました。

これにより、eストアがSQLInjectionsまたは同様の任意のコード実行にさらされることはありませんか？ このデータをデータベース内に保存する前にmagentoが実行する別のチェックはありますか？

4

1 に答える 1

0

以前の開発者が削除したフィルター関数は、SQLインジェクションやその他のセキュリティリスクの入力をフィルター処理するためには使用されません。これらは、ローカライズされた入力を、ロケールに関係なく処理できる標準形式に変換するために使用されます。最初のdiffの拡張コンテキストは次のとおりです。

$filter = new Zend_Filter_LocalizedToNormalized(
    array('locale' => Mage::app()->getLocale()->getLocaleCode())
);
$params['qty'] = $filter->filter($params['qty']);

LocalizedToNormalの機能の詳細については、Zendのドキュメントを参照してください。

Magentoには、クエリを作成する前にすべてのデータをフィルタリングする標準のデータベースクラスを使用して、SQLインジェクションを防ぐための保護機能が組み込まれています。このロジックは、Mage_Core_Model_Resource_ *クラスと、/ lib/Zendに格納されているZendライブラリにあります。以前の開発者がこれらのクラスを変更しなかった限り、追加のSQLリスクはありません。

もちろん、クロスサイトスクリプティングは常に潜在的な問題ですが、そこでのリスクは通常、コントローラーまたはモデルレイヤーよりもビューレイヤー（PHTMLおよびブロッククラス）にあります。

于 2012-08-26T16:28:51.810 に答える