标签：nginx

Magento SUPEE 6788

SUPEE-6788 is a bundle of patches that resolve several security-related issues.

Note: this patch bundle may possibly break backward compatibility with customizations or extensions. Please check the

technical detailspage.

You can find more details on the vulnerabilities address by this patch below:

Error Reporting in Setup Exposes Configuration - APPSEC-1102

Type:

Information Leakage (Internal)

CVSSv3 Severity:

7.5 (High)

Known Attacks:

None

Description:

Error messages generated during the Magento installation, or during a failed extension installation, can expose the Magento configuration and database access credentials. In most cases, the database server is configured to prevent external connections. In
other cases, the information can be exploited, or tied to another attack.

Product(s) Affected:

Magento CE prior to 1.9.2.2, and Magento EE prior to 1.14.2.2

Fixed In:

CE 1.9.2.2, EE 1.14.2.2

Reporter:

Albert Assmann

Filter Directives Can Allow Access to Protected Data - APPSEC-1057

Type:

Information Leakage

CVSSv3 Severity:

7.5 (High)

Known Attacks:

None

Description:

Email template filter functionality can be used to call blocks exposing customer information like last orders or integration passwords. While this functionality is used internally in Magento safely, we were informed about external extensions that use it
to process user input like blog comments. This allows to access protected information from store front.

Note: technical details on this issue are available
here.

Product(s) Affected:

Magento CE prior to 1.9.2.2, and Magento EE prior to 1.14.2.2

Fixed In:

CE 1.9.2.2, EE 1.14.2.2

Reporter:

Peter O'Callaghan

XXE/XEE attack on Zend XML functionality using multibyte payloads - APPSEC-1045

Type:

XXE/XEE (XML Injection)

CVSSv3 Severity:

7.5 (High)

Known Attacks:

None

Description:

Magento can be forced to read XML via API calls containing ENTITY references to local files, possibly reading password or configuration files. While Zend Framework filters out ENTITY references, they can be encoded as multi-byte characters to avoid detection.

This is a Zend Framework issue described here http://framework.zend.com/changelog/1.12.14/

Product(s) Affected:

Magento CE prior to 1.9.2.2, and Magento EE prior to 1.14.2.2

Fixed In:

CE 1.9.2.2, EE 1.14.2.2

Reporter:

Dawid Golunski

Potential SQL Injection in Magento Core Model Based Classes - APPSEC-1063

Type:

SQL Injection

CVSSv3 Severity:

7.4 (High)

Known Attacks:

None

Description:

addFieldtoFilter method does not escape field name. Although core Magento functionality is not affected, this issue might impact third-party extensions such as layered navigation extensions. Such extensions might be exploited from the storefront to execute
any SQL queries. 

Note: technical details on this issue are available here.

Product(s) Affected:

Magento CE prior to 1.9.2.2, and Magento EE prior to 1.14.2.2

Fixed In:

CE 1.9.2.2, EE 1.14.2.2

Reporter:

Jim O'Halloran/Aligent

Potential remote code execution using Cron - APPSEC-1037

Type:

Remote Code Execution (RCE)

CVSSv3 Severity:

7.2 (High)

Known Attacks:

None

Description:

Cron.php script is available for anyone to call and itself calls command line functions. It makes is a possible target for the Shellshock vulnerability (which should be fixed on the server). Additionally, the command passed to shell is not escaped, which
in case of a directory named as a shell command can result in code execution – such attack requires however additional access to create directories with arbitrary names, like hosting panel. While scored as high, the attack is not exploitable by itself.

Product(s) Affected:

Magento CE 1.8.0.0 - 1.9.2.1, and Magento EE 1.13.0.0 - 1.14.2.1

Fixed In:

CE 1.9.2.2, EE 1.14.2.2

Reporter:

Dawid Golunski

Remote Code Execution/Information Leak Using File Custom Option - APPSEC-1079

Type:

Remote Code Execution/Information Leak

CVSSv3 Severity:

6.5 (Medium)

Known Attacks:

None

Description:

Custom option values are not cleared when the custom option type is switched. This makes it possible to inject malicious serialized code into a custom option of the “text” type, and execute it by switching the custom option type to “file.”

To exploit this remote code execution attack the store has to use custom options and a store administration account with access to catalog/products.

Additionally, manipulation of custom options from the storefront makes it possible to read system files if store uses custom options.

Note: technical details on this issue are available here.

Product(s) Affected:

Magento CE prior to 1.9.2.2, and Magento EE prior to 1.14.2.2

Fixed In:

CE 1.9.2.2, EE 1.14.2.2

Reporter:

Peter O'Callaghan

Cross site scripting with error messages - APPSEC-1039

Type:

Cross-site Scripting (CSS) - reflected

CVSSv3 Severity:

6.1 (Medium)

Known Attacks:

None

Description:

Error messages on store front pages are not escaped correctly, enabling self XSS issue.

Product(s) Affected:

Magento CE prior to 1.9.2.2, and Magento EE prior to 1.14.2.2

Fixed In:

CE 1.9.2.2, EE 1.14.2.2

Reporter:

Ultra Security

Potential remote code execution using error reports and downloadable products - APPSEC-1032

Type:

Remote Code Execution (RCE)

CVSSv3 Severity:

6.1 (Medium)

Known Attacks:

None

Description:

It is possible to put unvalidated information (including code) into error report files. This attack could be tied with potential other attacks to execute the code in the report files. This issue is not exploitable itself.

Product(s) Affected:

Magento CE prior to 1.9.2.2, and Magento EE prior to 1.14.2.2

Fixed In:

CE 1.9.2.2, EE 1.14.2.2

Reporter:

Hannes Karlsson

 

Admin Path Disclosure - APPSEC-1034

Type:

Information Leakage (Internal)

CVSSv3 Severity:

5.3 (Medium)

Known Attacks:

None

Description:

Attacker can force showing admin panel login page regardless of admin panel URL by calling a module directly. It makes it easier to try automated password attacks and exposes admin URL on the page.

 

Note: technical details on this issue are available here.

Product(s) Affected:

Magento CE prior to 1.9.2.2, and Magento EE prior to 1.14.2.2

Fixed In:

CE 1.9.2.2, EE 1.14.2.2

Reporter:

Nils Preuss

Insufficient Protection of Password Reset Process - APPSEC-1027

Type:

Account Takeover

CVSSv3 Severity:

3.8 (Low)

Known Attacks:

None

Description:

The token to reset password is passed via a GET request and not cancelled after use. This means it leaks in the referrer field to all external services called on the page (image servers, analytics, ads) and can be potentially reused to steal customer password.

Product(s) Affected:

Magento CE prior to 1.9.2.2, and Magento EE prior to 1.14.2.2

Fixed In:

CE 1.9.2.2, EE 1.14.2.2

Reporter:

Vishnu Dfx

Dev Folder Not Protected - APPSEC-1124

Type:

Information Leakage (Internal)

CVSSv3 Severity:

0.0 (None)

Known Attacks:

None

Description:

The Magento dev folder, including functional tests, lacked a proper .htaccess file to prevent browser access. As a best practice, all files and directories that are not intended for public view should be protected.

Product(s) Affected:

Magento CE 1.9.2.0-1.9.2.1, and Magento EE 1.14.2.0-1.14.2.1

Fixed In:

CE 1.9.2.2, EE 1.14.2.2

Reporter:

Internal

For Magento Community Edition only prior to version 1.9.2.1:

Cross-site Scripting/Cache Poisoning - APPSEC-1030

Type:

Cross-site Scripting (XSS) - Stored / Cache Poisoning

CVSSv3 Severity:

9.3 (Critical)

Known Attacks:

None

Description:

Unvalidated host header leaks into response and page. Because the page can be cached, this leak poses a risk for all store customers because any HTML or JavaScript code can be injected. Such an exploit works only with specific server configurations, and
allows an attacker to intercept a session or modify a page with fake credit card forms, etc.

Note: While this issue is not applicable to out of the box Magento Community installations, it could possibly be exploited with 3rd party full page caching extensions. This patch was also already included in 1.9.2.1 release.

Product(s) Affected:

Magento CE prior to 1.9.2.1

Fixed In:

EE 1.14.2.1

Reporter:

Internal (ECG)

此文章通过 python 爬虫创建，原文是自己的csdn 地址: Magento SUPEE 6788

Nginx重定向[Rewrite]配置

nginx rewrite 各参数意义

$arg_PARAMETER #这个变量包含GET请求中，如果有变量PARAMETER时的值。

$args #这个变量等于请求行中(GET请求)的参数，例如foo=123&bar=blahblah;

$binary_remote_addr #二进制的客户地址。

$body_bytes_sent #响应时送出的body字节数数量。即使连接中断，这个数据也是精确的。

$content_length #请求头中的Content-length字段。

$content_type #请求头中的Content-Type字段。

$cookie_COOKIE #cookie COOKIE变量的值

$document_root #当前请求在root指令中指定的值。

$document_uri #与$uri相同。

$host #请求主机头字段，否则为服务器名称。

$hostname #Set to the machine’s hostname as returned by gethostname

$http_HEADER

$is_args #如果有$args参数，这个变量等于”?”，否则等于””，空值。

$http_user_agent #客户端agent信息

$http_cookie #客户端cookie信息

$limit_rate #这个变量可以限制连接速率。

$query_string #与$args相同。

$request_body_file #客户端请求主体信息的临时文件名。

$request_method #客户端请求的动作，通常为GET或POST。

$remote_addr #客户端的IP地址。

$remote_port #客户端的端口。

$remote_user #已经经过Auth Basic Module验证的用户名。

$request_completion #如果请求结束，设置为OK. 当请求未结束或如果该请求不是请求链串的最后一个时，为空(Empty)。

$request_method #GET或POST

$request_filename #当前请求的文件路径，由root或alias指令与URI请求生成。

$request_uri #包含请求参数的原始URI，不包含主机名，如：”/foo/bar.php?arg=baz”。不能修改。

$scheme #HTTP方法（如http，https）。

$server_protocol #请求使用的协议，通常是HTTP/1.0或HTTP/1.1。

$server_addr #服务器地址，在完成一次系统调用后可以确定这个值。

$server_name #服务器名称。

$server_port #请求到达服务器的端口号。

$uri #不带请求参数的当前URI，$uri不包含主机名，如”/foo/bar.html”。该值有可能和$request_uri 不一致。$request_uri是浏览器发过来的值。该值是rewrite后的值。例如做了internal redirects后。

今 天在给某网站写rewrite重定向规则时，碰到了这个关于重定向的参数处理问题。默认的情况下，Nginx在进行rewrite后都会自动添加上旧地址 中的参数部分，而这对于重定向到的新地址来说可能是多余。虽然这也不会对重定向的结果造成多少影响，但当你注意到新地址中包含有多余的“?xxx=xxx”时，心里总还是会觉得不爽。那么该如何来处理这部分的内容呢？看了下面两个简单的例子你就会明白了。

例如：
把http://example.com/test.php?para=xxx 重定向到 http://example.com/new
若按照默认的写法：rewrite ^/test.php(.*) /new permanent;
重定向后的结果是：http://example.com/new?para=xxx
如果改写成：rewrite ^/test.php(.*) /new? permanent;
那结果就是：http://example.com/new

所以，关键点就在于“？”这个尾缀。假如又想保留某个特定的参数，那又该如何呢？可以利用Nginx本身就带有的$arg_PARAMETER参数来实现。

例如：
把http://example.com/test.php?para=xxx&p=xx 重写向到 http://example.com/new?p=xx
可以写成：rewrite ^/test.php /new?p=$arg_p? permanent;

只求结果的朋友可以直接忽略前面的内容，看这里：

rewrite  ^/test.php  /new  permanent;       //重写向带参数的地址

    rewrite  ^/test.php  /new?  permanent;      //重定向后不带参数

    rewrite  ^/test.php   /new?id=$arg_id?  permanent;    //重定向后带指定的参数

permanent是永久重定向参数，根据需要去掉也可以，不过最好是带有。
参考301重定向与302重定向的区别

首先Apache的Rewite规则差别不是很大,但是Nginx的Rewrite规则比Apache的简单灵活多了
Nginx可以用if进行条件匹配，语法规则类似C

if ($http_user_agent ~ MSIE) {
rewrite ^(.*)$ /msie/$1 break;
}

Rewrite的Flags

Flags can be any of the following:
* last - completes processing of rewrite directives, after which searches for corresponding URI and location
* break - completes processing of rewrite directives
*redirect - returns temporary redirect with code 302; it is used if the substituting line begins with http://
* permanent - returns permanent redirect with code 301

last – 完成重写指令后，搜索相应的URI和位置。相当于Apache里的[L]标记，表示完成rewrite，不再匹配后面的规则。
break – 中止Rewirte，不在继续匹配。
redirect – 返回临时重定向的HTTP状态302。
permanent – 返回永久重定向的HTTP状态301。

ZEND Framework的重定向规则：
案例一：
全部重定向到 /index.php

rewrite ^/(.*) /index.php?$1&;

案例二：
如果文件或目录不存在则重定向到index.php

if (!-e $request_filename) {
rewrite ^/(.*) /index.php?$1&;
}

WordPress的重定向规则：
案例一：
http://www.wemvc.com/12 重定向到 http://www.wemvc.com/index.php?p=12

if (!-e $request_filename) {
rewrite ^/(.+)$ /index.php?p=$1 last;
}

案例二：
与zendframework配置很像

if (!-e $request_filename) {
rewrite ^/(.*) /index.php?$1&;
}

以下为Discuz完整的Rewrite for Nginx规则

if (!-f $request_filename) {
rewrite ^/archiver/((fid|tid)-[w-]+.html)$ /archiver/index.php?$1 last;
rewrite ^/forum-([0-9]+)-([0-9]+).html$ /forumdisplay.php?fid=$1&page=$2 last;
rewrite ^/thread-([0-9]+)-([0-9]+)-([0-9]+).html$ /viewthread.php?tid=$1&extra=page=$3&page=$2 last;
rewrite ^/space-(username|uid)-(.+).html$ /space.php?$1=$2 last;rewrite ^/tag-(.+).html$ /tag.php?name=$1 last;
}

文件及目录匹配，其中：
-f和!-f用来判断是否存在文件
-d和!-d用来判断是否存在目录
-e和!-e用来判断是否存在文件或目录
-x和!-x用来判断文件是否可执行

正则表达式全部符号解释
~ 为区分大小写匹配
~* 为不区分大小写匹配
!~和!~* 分别为区分大小写不匹配及不区分大小写不匹配
(pattern) 匹配 pattern 并获取这一匹配。所获取的匹配可以从产生的 Matches 集合得到，在VBScript. 中使用 SubMatches 集合，在JScript. 中则使用 $0…$9 属性。要匹配圆括号字符，请使用 ‘(’ 或 ‘)’。
^ 匹配输入字符串的开始位置。
$ 匹配输入字符串的结束位置。

$(function () {
$('pre.prettyprint code').each(function () {
var lines = $(this).text().split('n').length;
var $numbering = $('

    ').addClass('pre-numbering').hide();
    $(this).addClass('has-numbering').parent().append($numbering);
    for (i = 1; i <= lines; i++) {
    $numbering.append($('
  • ').text(i));
    };
    $numbering.fadeIn(1700);
    });
    });

此文章通过 python 爬虫创建，原文是自己的csdn 地址: Nginx重定向[Rewrite]配置