shopex跟ecshop哪个比较好，有什么区别？

ShopEx与ECShop是目前国内市场占有率最高的两款PHP网上商店系统。论出道时间，ShopEx较长，而ECShop虽是后起之秀，却也当仁不让，凭借着自己的诸多优势赢得了广大用户的青睐。两个平台目前隶属于同一家公司，如果你搞纯运营，不考虑个性化发展和二次开发。你可以使用shopex。

一、安装与登录

在安装方面，ECShop更为方便，它对环境配置要求低，不需要zend环境，安装相对容易。安装好后，进入登录界面。ECShop登录界面，在界面的左边，大大的“ECShop”图标，显示出设计者比较有品牌宣传的意识。

ShopEx的登录界面很有质感，也很漂亮。但没有“忘记密码”的问题解决入口，显得不那么人性化。

二、后台管理

ECShop的后台管理界面，所有的功能都罗列在页面左栏中。

ShopEx的后台管理界面，所有功能采用弹出标签来显示。

相比较，ECShop的后台管理界面更加大气。另外，后台操作起来也更加简洁快捷些，所有功能都罗列在左侧，“所点即所得”。ShopEx的后台需要先点下“功能”按钮，弹出标签后再选择所要操作的功能，相对烦琐些。

三、商品管理

ECShop支持商品相册，关联商品，关联文章，配件等。允许商品属于多个商品分类，可后台设置商品属性，不同属性可对应不同价格。ECShop使用插件机制实现虚拟商品管理功能。目前提供虚拟卡插件，该插件实现了游戏点卡、网卡等的在线取卡与卡信息批量上传等功能。提供对商品加标签功能，方便用户查找和分类。支持虚拟商品。

ShopEx支持商品的批量处理和数据导入，提供快捷方便的商品修改功能；支持组配商品销售和加价购买的方式以及商品捆绑促销；提供点卡、网卡、电子图书等非实体或数字商品的销售功能，在线取卡、在线充值与卡信息批量上传。

在模板管理方面，ECShop提供模板的自定义功能，可以让网店设计者设计出更加美观的网店页面。另外，ECShop还提供了ShopEx转换成ECShop的数据转换功能。

四、支付方式

Ecshop预先整合了国内十几种主流的在线支付接口，比如支付宝、银行汇款、财付通、网银在线、快钱等。您只需要和第三方支付公司签约后，在网站后台简单填写一下商户号密钥即可立即开通使用支付功能。

ShopEx采用的是内置银联、快钱、支付宝等国际国内三十几个网上支付网关。ShopEx以功能全面、易用、强大见长；而ECShop却以完全免费开源，和灵活的插件机制取胜。

五、开源性

ECShop完全开源、免费，定制性，扩展性强。

ShopEx只是前台开源，小信使、提醒工具、后台生成静态页面的文件等都是加密的，不能进行修改和再次开发。

六、实用性

你如果打算把网店做大，那么你还是放弃shopex很多绚丽的功能吧。用稍微土一点的ecshop。Php不是很难学，慢慢的，你会不断的改变ecshop，时间一久，符合你需求的个性化的独立商城，将能更好的黏住用户。

shopex也不错，对不懂PHP技术的人来讲，shopex比ECSHOP用起来方便很多，包括模板很丰富，看各自需求。

之前在工作中经常用密钥，但是不知道其中的原因，现在闲下来就来看下，再看的过程发现这个随机数概念很模糊，于是就查了下，现总结如下：

　0x01 随机数

概述

随机数在计算机应用中使用的比较广泛，最为熟知的便是在密码学中的应用。本文主要是讲解随机数使用导致的一些Web安全风。

我们先简单了解一下随机数

分类

随机数分为真随机数和伪随机数，我们程序使用的基本都是伪随机数，其中伪随机又分为强伪随机数和弱伪随机数。

真随机数，通过物理实验得出，比如掷钱币、骰子、转轮、使用电子元件的噪音、核裂变等

伪随机数，通过一定算法和种子得出。软件实现的是伪随机数

强伪随机数，难以预测的随机数

弱伪随机数，易于预测的随机数

特性

随机数有3个特性，具体如下：

随机性：不存在统计学偏差，是完全杂乱的数列

不可预测性：不能从过去的数列推测出下一个出现的数

不可重现性：除非将数列本身保存下来，否则不能重现相同的数列

随机数的特性和随机数的分类有一定的关系，比如，弱伪随机数只需要满足随机性即可，而强位随机数需要满足随机性和不可预测性，真随机数则需要同时满足3个特性。

引发安全问题的关键点在于不可预测性。

伪随机数的生成

我们平常软件和应用实现的都是伪随机数，所以本文的重点也就是伪随机数。

伪随机数的生成实现一般是算法+种子。

具体的伪随机数生成器PRNG一般有：

线性同余法

单向散列函数法

密码法

ANSI X9.17

比较常用的一般是线性同余法，比如我们熟知的C语言的rand库和Java的java.util.Random类，都采用了线性同余法生成随机数。

应用场景

随机数的应用场景比较广泛，以下是随机数常见的应用场景：

验证码生成

抽奖活动

UUID生成

SessionID生成

Token生成

CSRF Token

找回密码Token

游 戏 (随机元素的生成)

洗牌

俄罗斯方块出现特定形状的序列

游戏爆装备

密码应用场景

生成密钥：对称密码，消息认证

生成密钥对：公钥密码，数字签名

生成IV： 用于分组密码的CBC，CFB和OFB模式

生成nonce: 用于防御重放攻击分组密码的CTR模式

生成盐：用于基于口令的密码PBE等

0x02 随机数的安全性

相比其他密码技术，随机数很少受到关注，但随机数在密码技术和计算机应用中是非常重要的，不正确的使用随机数会导致一系列的安全问题。

随机数的安全风险

随机数导致的安全问题一般有两种

应该使用随机数，开发者并没有使用随机数

应该使用强伪随机数，开发者使用了弱伪随机数。

第一种情况，简单来讲，就是我们需要一个随机数，但是开发者没有使用随机数，而是指定了一个常量。当然，很多人会义愤填膺的说，sb才会不用随机数。但是，请不要忽略我朝还是有很多的。主要有两个场景：

开发者缺乏基础常识不知道要用随机数

一些应用场景和框架，接口文档不完善或者开发者没有仔细阅读等原因。

比如找回密码的token，需要一个伪随机数，很多业务直接根据用户名生成token

比如OAuth2.0中需要第三方传递一个state参数作为CSRF Token防止CSRF攻击，很多开发者根本不使用这个参数，或者是传入一个固定的值。由于认证方无法对这个值进行业务层面有效性的校验，导致了 OAuth 的CSRF攻击。

第二种情况，主要区别就在于伪随机数的强弱了，大部分(所有?)语言的API文档中的基础库(常用库)中的random库都是弱伪随机，很多开发自然就直接使用。但是，最重要也最致命的是，弱伪随机数是不能用于密码技术的。

还是第一种情况中的找回密码场景，关于token的生成， 很多开发使用了时间戳作为随机数(md5(时间戳)，md5(时间戳+用户名))，但是由于时间戳是可以预测的，很容易就被猜解。不可预测性是区分弱伪随机数和强伪随机数的关键指标。

当然，除了以上两种情况，还有一些比较特别的情况，通常情况下比较少见，但是也不排除：

种子的泄露，算法很多时候是公开的，如果种子泄露了，相当于随机数已经泄露了

随机数池不足。这个严格来说也属于弱伪随机数，因为随机数池不足其实也导致了随机数是可预测的，攻击者可以直接暴力破解。

漏洞实例

wooyun上有很多漏洞，还蛮有意思的，都是和随机数有关的。

1.应该使用随机数而未使用随机数

Oauth2.0的这个问题特别经典，除了wooyun实例列出来的，其实很多厂商都有这个问题。

Oauth2.0中state参数要求第三方应用的开发者传入一个CSRF Token(随机数)，如果没有传入或者传入的不是随机数，会导致CSRF登陆任意帐号：

唯品会账号相关漏洞可通过csrf登录任意账号

人人网 - 百度 OAuth 2.0 redirect_uir CSRF 漏洞

2.使用弱伪随机数

1) 密码取回

很多密码找回的场景，会发 送给 用户邮件一个url，中间包含一个token，这个token如果猜测，那么就可以找回其他用户的密码。

1. Shopex  4.8.5密码取回处新生成密码可预测漏洞

直接使用了时间函数microtime()作为随机数，然后获取MD5的前6位。

1. substr(md5(print_r(microtime(),true)),0,6)

PHP 中microtime()的值除了当前 服务器 的秒数外，还有微秒数，微妙数的变化范围在0.000000 -- 0.999999 之间，一般来说，服务器的时间可以通过HTTP返回头的DATE字段来获取，因此我们只需要遍历这1000000可能值即可。但我们要使用暴力破解的方式发起1000000次请求的话，网络请求数也会非常之大。可是shopex非常贴心的在生成密码前再次将microtime() 输出了一次：

1. $messenger = &$this->system->loadModel('system/messenger')echo microtime()."

"

2.奇虎360任意用户密码修改

直接是MD5( unix 时间戳)

3.涂鸦王国弱随机数导致任意用户劫持漏洞，附测试POC

关于找回密码随机数的问题强烈建议大家参考拓哥的11年的文章《利用系统时间可预测破解java随机数| 空虚浪子心的灵魂》

2) 其他随机数验证场景

CmsEasy最新版暴力注入(加解密缺陷/绕过防注入)

弱伪随机数被绕过

Espcms v5.6 暴力注入

Espcms中一处SQL注入漏洞的利用，利用时发现espcms对传值有加密并且随机key,但是这是一个随机数池固定的弱伪随机数，可以被攻击者遍历绕过

Destoon B2B  2014-05-21最新版绕过全局防御暴力注入(官方Demo可重现)

使用了microtime()作为随机数，可以被预测暴力破解

Android  4.4之前版本的Java加密架构(JCA)中使用的Apache Harmony 6.0M3及其之前版本的SecureRandom实现存在安全漏洞，具体位于classlib/modules/security/src/main/java/common/org/apache/harmony/security/provider/crypto/SHA1PRNG_SecureRandomImpl.java

类的engineNextBytes函数里，当用户没有提供用于产生随机数的种子时，程序不能正确调整偏移量，导致PRNG生成随机序列的过程可被预测。

Android SecureRandom漏洞详解

安全建议

上面讲的随机数基础和漏洞实例更偏重是给攻击者一些思路，这里更多的是一些防御和预防的建议。

业务场景需要使用随机数，一定要使用随机数，比如Token的生成

随机数要足够长，避免暴力破解

保证不同用处的随机数使用不同的种子

对安全性要求高的随机数(如密码技术相关)禁止使用的弱伪随机数：

不要使用时间函数作为随机数(很多程序员喜欢用时间戳) Java：system.currenttimemillis() php：microtime()

不要使用弱伪随机数生成器 Java: java.util.Random PHP: rand() 范围很小，32767 PHP: mt_rand() 存在缺陷

强伪随机数CSPRNG(安全可靠的伪随机数生成器(Cryptographically Secure  Pseudo-Random Number Generator)的各种参考

6.强伪随机数生成(不建议开发自己实现)

产生高强度的随机数，有两个重要的因素：种子和算法。算法是可以有很多的，通常如何选择种子是非常关键的因素。 如Random，它的种子是System.currentTimeMillis()，所以它的随机数都是可预测的， 是弱伪随机数。

强伪随机数的生成思路：收集计算机的各种，键盘输入时间，内存使用状态，硬盘空闲空间，IO延时，进程数量，线程数量等信息，CPU时钟，来得到一个近似随机的种子，主要是达到不可预测性。

暂时先写到这里

登录就是使用你安装最初的用户名和密码。如果记错了的话从新下载一个再使用，看看可以吗？

电脑IE点右键-安全-受信任站点-降低一下安全级别试试。

3.2在官方下的在你确认用户名和密码没错的情况下问题出在你电脑上

---