【挖掘笔记】web应用安全测试之业务漏洞

admin 2022年1月5日16:35:50安全文章评论31 views9904字阅读33分0秒阅读模式

【挖掘笔记】web应用安全测试之业务漏洞

网安教育

培养网络安全人才

技术交流、学习咨询



业务逻辑篡改


密码修改/重置流程跨越


漏洞描述

密码修改功能常采用分步骤方式来实现,攻击者在未知原始密码的情况下绕过某些检验步骤修改用户密码。


测试方法:

完成修改/重置密码的正常流程;

绕过检验原密码等步骤,直接访问输入新密码页面,输入新密码,修改/重置密码。


风险分析:

有些密码修改/重置流程采用step=1、step=2类似的方式实现,如果应用校验不全面,

攻击者可绕过前面的步骤,直接访问最后一步,输入新密码进行修改/重置。


风险等级:

【高危】:绕过原密码验证或绕过验证码


修复方案

1一次性填写校验信息(原始密码、新密码等)后再提交修改/重置密码请求。


负值反冲


漏洞描述

应用程序未校验订单数据的取值范围,交易存在负值反冲。


测试方法

提交订单时拦截请求,修改订单参数为负数,如商品单价、数量、总价等。


风险分析

通过篡改订单参数,使得订单金额为负值,在使用余额支付时余额反而增加。


风险等级

【高危】:未对数据进行校验,导致业务数据被污染。


修复方案:

1.服务器端在生成交易订单时,商品的价格从数据库中取出,禁止使用客户端发送的商品价格。

2.服务器端对客户端提交的交易数据(如商品ID、商品数量、商品价格等)的取值范围进行校验,将商品ID和商品价格与数据库中的数据对比校验,商品数量为大于零的整型数。

3.服务器端在生成支付订单时,对支付订单中影响支付金额的所有因素(比如商品ID、商品数量、商品价格、订单编号等)进行签名,对客户端提交的支付订单进行校验。


正负值对冲


漏洞描述

应用程序未校验订单数据的取值范围,交易存在正负值对冲。


测试方法

提交订单(包含多种商品)时拦截请求,修改部分商品的单价或数量,保证订单总金额为正数。


风险分析

由于应用会校验订单总金额的取值范围,所以在保证该条件满足的前提下,修改个别商品的数量,达到正负值对冲。


风险等级:

【高危】:未对数据进行校验,导致业务数据被污染。


修复方案:

1服务器端在生成交易订单时,商品的价格从数据库中取出,禁止使用客户端发送的商品价格。
2服务器端对客户端提交的交易数据(如商品ID、商品数量、商品价格等)的取值范围进行校验,将商品ID和商品价格与数据库中的数据对比校验,商品数量为大于零的整型数。
3服务器端在生成支付订单时,对支付订单中影响支付金额的所有因素(比如商品ID、商品数量、商品价格、订单编号等)进行签名,对客户端提交的支付订单进行校验。


业务流程跳跃


漏洞描述

业务逻辑流程分步骤进行且能越过中间校验步骤直接进行后续操作,导致中间校验等步骤失效。


测试方法:

首先完成正常的业务逻辑步骤,获取每一个步骤的请求;

绕过中间步骤,直接访问最后一个或几个验证请求,看是否可绕过。


风险分析

攻击者可利用该漏洞绕过业务流程检测,进行非法修改他人密码等危险操作。


风险等级:

【高危】:绕过前面的校验步骤,直接跳转至后面的校验步骤。


修复方案

建议在不影响业务的前提下,在Session中添加对每一步流程页面的校验标志位,在新步骤页面浏览过程中,仅能够顺序执行页面校验,不可进行跳步操作,例如:页面二完成后,应更新Flag=3,则仅能够打开页面三。


业务功能失效

通配符注入


漏洞描述

允许使用通配符构造语句查询数据库,导致拒绝服务攻击问题。


测试方法

模糊查询时输入第一个字符’%‘或’_’,sql会遍历全表,导致应用访问缓慢。

风险分析:SQL中通配符的使用如下:

1%包含零个或多个字符的任意字符串。
2_任何单个字符。
3[]指定范围(例如 [a-f])或集合(例如 [abcdef])内的任何单个字符。
4[^]不在指定范围(例如 [^a - f])或集合(例如 [^abcdef])内的任何单个字符。
5在模糊查询LIKE中,对于输入数据中的通配符必须转义,否则会造成客户想查询包含这些特殊字符的数据时,这些特殊字符却被解析为通配符,数据库响应缓慢,导致拒绝服务攻击。


风险等级:

【中危】:通配符注入引发数据库响应缓慢


修复方案

 1有两种将通配符转义为普通字符的方法:
2
31)   使用ESCAPE关键字定义转义符(通用)
4在模式中,当转义符置于通配符之前时,该通配符就解释为普通字符。例如,要搜索在任意位置包含字符串 5% 的字符串,请使用:
5    WHERE ColumnA LIKE '%5/%%' ESCAPE '/'
62)   在方括号 ([ ]) 中只包含通配符本身,或要搜索破折号 (-) 而不是用它指定搜索范围,请将破折号指定为方括号内的第一个字符。例如:
7符号    含义
8LIKE '5[%]'    5%
9LIKE '5%'    5 后跟 0 个或多个字符的字符串
10LIKE '[_]n'    _n
11LIKE '[ [ ]'    [
12LIKE ']'    ]   (右括号不需要转义)
13
14所以,对输入参数的关键字过滤后,还需要做下面转换确保LIKE的正确执行
15private static string ConvertSqlForLike(string sql)
16
{
17sql = sql.Replace("[",
18"[[]");
19// 这句话一定要在下面两个语句之前,否则作为转义符的方括号会被当作数据被再次处理
20sql = sql.Replace("_",
21"[_]");
22sql = sql.Replace("%",
23"[%]");
24returnsql;
25}


业务功能滥用

短信定向转发


漏洞描述

短信接收人可任意指定


测试方法

拦截发送短信的请求,将手机号改为测试人员的手机号,测试是否可接收短信验证码。


风险分析

攻击者可利用该漏洞将验证码发送到自己的手机号上,重置他人密码或转账。


风险等级

【高危】:短信接收人可任意指定


修复方案

发送短信时手机号从当前会话中获取,避免从前端传入。


邮件可定向转发


漏洞描述

应用系统发送邮件的接收人可由客户端任意指定


测试方法:=

拦截发送邮件的请求,将接收人邮箱改为测试人员的邮箱地址,测试是否可接收邮件。


风险分析

攻击者可利用该漏洞将邮件发送到自己的邮箱中,重置他人密码。


风险等级:

【高危】:邮件接收人可任意指定


修复方案

发送邮件时邮箱从当前会话中获取,避免从前端传入。


业务接口调用缺陷


漏洞描述

应用的业务接口存在缺陷,可以通过业务接口直接进行恶意操作。


测试方法

把业务逻辑和功能模块呈现的内容结合,推测出隐藏的API接口。

如用户信息的接口是http://www.xxx.com/api/user/userInfo,推测重置密码接口可能是http://www.xxx.com/api/user/passReset,文件上传接口是http://www.xxx.com/api/user/uploadFile等。

如果这些接口没有限制访问,则可以直接调用并提交数据。

针对开源或商业软件的业务接口调用缺陷可参考《通用系统安全测试指导文档》


风险分析

攻击者可通过编写API枚举脚本,恶意调用敏感接口,从而进行提交数据等操作。


风险等级:

【高危】:通过业务接口能够操作核心业务内容,进行越权

【高危】:通过业务接口能够获得重要敏感数据

【中危】:通过业务接口能够获得中等程度敏感数据


修复方案

对于每一个访问的接口都首先检查当前用户是否已经登录并授权(不需要认证的接口除外,例如,免费下载接口等)。


IMAP/SMTP注入


漏洞描述

和广为人知的诸如SQL注入、XPath注入等技术类似,邮件服务器注入技术也是通过一个对用户提供的数据没有严格检查的webmail应用程序将IMAP命令或者SMTP命令注入到邮件服务器。

要向邮件服务器注入命令,前提条件是允许用户通过webmail应用程序访问其端口25(SMTP)和143(IMAP)。


测试方法

要利用SMTP注射,用户必须事先通过认证,所以用户必须有一个有效的webmail帐户。通过SMTP发送电子邮件消息的格式如下:

1发送方的e-mail地址 
2接收方的e-mail地址 
3主题 
4消息主体 
5附件


CC/BCC注入

1在发送者字段(sender)后注入CC和BCC参数
2From:[email protected]%0ACc:[email protected]%0ABcc:[email protected]
3所以现在,消息将被发送到recipient和recipient1账户。


参数注射

1From:[email protected]%0ATo:[email protected]
2现在消息将被发送到原来的收件人和攻击者帐户。注意,这里的攻击者的账户是我们通过注入额外传入的。


邮件主题注入

1From:[email protected]%0ASubject:This’s%20Fake%20Subject
2攻击者注入的假的主题subject将被添加到原来的主题中并且在某些情况下将取代原本的主题subject。这取决于邮件服务行为。即代码编写的容错性,当参数中出现两个subject的时候代码是选择丢弃还是后者覆盖。


改变消息的主体body

1要注意SMTPMail格式,消息主题和头部Header之间有两个换行符(和HTTP是一样的)。
2From:sender@domain.com%0A%0AMy%20New%20%0Fake%20Message.
3假消息将被添加到原始消息中。


风险分析

电子邮件注入允许恶意攻击者注入任意邮件头字段,BCC、CC、主题等,它允许黑客通过注入手段从受害者的邮件服务器发送垃圾邮件。


风险等级:

【高危】:可成功劫持密码找回等信息

【高危】:可成功发送垃圾邮件


修复方案

建议从以下几个方面进行防御:

1.所有用户输入应该被认为是不可信的。使用正则表达式来过滤用用户提交的数据。例如,可以在输入字符串中搜索(r 或 n)。

2.使用外部组件和库,例如ZEND mail、PEAR mail和swift mailer。

3.ModSecurity可以阻止服务器级别的电子邮件注入。利用ModSecurity,可以检测通过POST或GET提交的CC, BCC或目的地址,并且拒绝任何包含这些字母请求。


引用第三方不可控脚本/URL


漏洞描述

页面中引用了不可控的脚本或超链接


测试方法

检查页面内容,是否引用了第三方未知脚本或超链接,如恶意的js脚本或病毒木马的下载链接等。


风险分析

攻击者可在网站中插入恶意链接或脚本,导致正常用户浏览时cookie被窃取或被种植病毒木马。


风险等级:

【高危】:存在不可控外链或脚本,且未经过审批

【中危】:存在不可控外链或脚本,但可提供审批记录


修复方案

建议在不影响业务的前提下,对网站引用的文件和源代码进行审查,一经发现有未审批的外链或脚本,应立即删除。


开启危险接口


漏洞描述

开启可利用的危险接口,如获取订单信息、用户身份信息等。


测试方法:

使用扫描器扫描特殊目录和链接

根据正常接口的命名特征猜测隐藏的危险接口,如获取个人信息接口是getUserInfo,猜测获取订单信息接口getOrderDetail。


风险分析

开启了危险接口,如订单信息打印、上传、web管理控制台等,可能被攻击者发现并利用,直接操作应用数据,造成数据泄漏等风险。


风险等级:

【高危】:正常情况接口是在认证之后被调用,如果可公网直接无认证使用

【中危】:存在特权、非正常用户不可知但可利用接口


修复方案:

1.敏感接口增加访问控制,避免未授权访问;

2.用户访问接口需校验权限,避免越权访问。


未验证的URL跳转


漏洞描述

服务端未对传入的跳转url变量进行检查和控制,可能导致可恶意构造任意一个恶意地址,诱导用户跳转到恶意网站。

由于是从可信的站点跳转出去的,用户会比较信任,所以跳转漏洞一般用于钓鱼攻击,通过转到恶意网站欺骗用户输入用户名和密码盗取用户信息,或欺骗用户进行金钱交易;

也可能引发的XSS漏洞(主要是跳转常常使用302跳转,即设置HTTP响应头,Locatioin: url,如果url包含了CRLF,则可能隔断了http响应头,使得后面部分落到了http body,从而导致xss漏洞)。

另外在struts2 中存在重定向的漏洞,是因为struts2由于缩写的导航和重定向前缀“action:”、 “redirect:”、 “redirectAction:” 等参数前缀的内容没有被正确过滤导致的开放式重定向漏洞。


测试方法:

首先找到网站相关url中存在跳转链接的参数(如登陆页面)。

在检测的同时,可以修改参数中的合法URL为非法URL,然后查看是否能正常跳转或者通过抓包工具获取其HTTP响应头中Host:的值是否包含了构造的URL。

如果是struts2重定向漏洞,则可通过web扫描工具扫描发现,或者手工验证,直接在URL后添加?redirect:+指定钓鱼链接,例如:10.1.82.53:9098/admin/login.action?redirect:http://diaoyu.com进行验证。


风险分析

攻击者利用URL跳转漏洞来欺骗安全意识低的用户,从而导致“中奖”之类的欺诈事件发生。

同时利用URL跳转,也可以突破常见的基于“白名单方式”的一些安全限制,如传统IM里对于URL的传输会进行安全校验,

但是对于知名网站的域名及URL将直接允许通过并且显示为可信的URL,一旦该可信的URL里包含URL跳转漏洞将导致安全限制被绕过。

URL跳转最典型的例子就是登录跳转,示例代码如下:

1public void doRedirect(HttpServletRequest req, HttpServletResponse res)
2
{
3   String jumpURL=request.getParameter(“jumptoURL”);
4    response.setHeader("Location",jumpURL);
5}
6若程序未过滤jumptoURL参数,攻击者将恶意链接:http://www.xxx.com/login.jsp?jumptoURL=http://www.evil.com发给其他用户,
7安全意识较低的用户会认为该链接展现的内容是www.xxx.com,从而产生欺诈行为。
8同时由于QQ、淘宝旺旺等在线IM都是基于URL的过滤,对部分站点会通过白名单的方式直接通过,因此恶意URL可以在IM里传播。
9例如IM认为www.xxx.com是可信的,但是通过在IM里点击上述链接将导致用户最终访问http://www.evil.com。


风险等级:

【高危】:URL 跳转参数可控,且未对参数做白名单限制导致任意地址跳转可被利用钓鱼。


修复方案

对传入的URL做有效性的认证,保证该URL来自于信任域。限制的方式可参考以下两种:

1限制Referer(Referer是HTTP header中的字段,当浏览器向web服务器发送请求时,一般会带上Referer,告诉服务器是从哪个页面链接过来的),通过限制Referer保证将要跳转URL的有效性,避免攻击者生成自己的恶意跳转链接;

2加入有效性验证Token,保证所有生成的链接都来自于可信域,通过在生成的链接里加入用户不可控的Token对生成的链接进行校验。


服务器端请求伪造(SSRF)


漏洞描述

服务端请求伪造攻击(Server-side Request Forgery): 很多web应用都提供了从其他的服务器上获取数据的功能。

使用用户指定的URL,web应用可以获取图片,下载文件,读取文件内容等。

这个功能如果被恶意使用,可以利用存在缺陷的web应用作为代理攻击远程和本地的服务器。

这种形式的攻击称为服务端请求伪造攻击(Server-side Request Forgery)。

一般情况下, SSRF攻击的目标是从外网无法访问的内部系统 。( 正是因为它是由服务端发起的,所以它能够请求到与它相连而与外网隔离的内部系统 ).

SSRF 形成的原因大都是由于 服务端提供了从其他服务器应用获取数据的功能且没有对目标地址做过滤与限制 。

比如从指定URL地址获取网页文本内容,加载指定地址的图片,下载等等。

攻击者利用ssrf可以实现的攻击主要有5种:

1可以对外网、服务器所在内网、本地进行端口扫描,获取一些服务的banner信息;
2攻击运行在内网或本地的应用程序(比如溢出);
3对内网web应用进行指纹识别,通过访问默认文件实现;
4攻击内外网的web应用,主要是使用get参数就可以实现的攻击(比如struts2,sqli等);
5利用file协议读取本地文件等。


测试方法

从WEB功能上寻找:我们从上面的概述可以看出,SSRF是由于服务端获取其他服务器的相关信息的功能中形成的,

因此我们大可以列举几种在web 应用中常见的从服务端获取其他服务器信息的的功能。

1通过分享功能:通过URL地址分享网页内容:
2早期分享应用中,为了更好的提供用户体验,WEB应用在分享功能中,通常会获取目标URL地址网页内容中的<tilte></title>标签或者<meta name="description" content=“”/>标签中content的文本内容作为显示以提供更好的用户体验。例如人人网分享功能中:http://widget.renren.com/*****?resourceUrl=https://www.nsfocus.com
3通过目标URL地址获取了title标签和相关文本内容。而如果在此功能中没有对目标地址的范围做过滤与限制则就存在着SSRF漏洞.
4转码服务:通过URL地址把原地址的网页内容调优使其适合手机屏幕浏览:由于手机屏幕大小的关系,直接浏览网页内容的时候会造成许多不便,因此有些公司提供了转码功能,把网页内容通过相关手段转为适合手机屏幕浏览的样式。例如百度、腾讯、搜狗等公司都有提供在线转码服务。
5在线翻译:通过URL地址翻译对应文本的内容。提供此功能的国内公司有百度、有道等。
6图片加载与下载,通过URL地址加载或下载图片:图片加载远程图片地址此功能用到的地方很多,但大多都是比较隐秘,比如在有些公司中的加载自家图片服务器上的图片用于展示。(此处可能会有人有疑问,为什么加载图片服务器上的图片也会有问题,直接使用img标签不就好了? ,没错是这样,但是开发者为了有更好的用户体验通常对图片做些微小调整例如加水印、压缩等,所以就可能造成SSRF问题)。
7图片、文章收藏功能:此处的图片、文章收藏中的文章收藏就类似于功能一、分享功能中获取URL地址中title以及文本的内容作为显示,目的还是为了更好的用户体验,而图片收藏就类似于功能四、图片加载。
8未公开的api实现以及其他调用URL的功能:此处类似的功能有360提供的网站评分,以及有些网站通过api获取远程地址xml文件来加载内容.


风险分析

如果应用程序对用户提供的URL和远端服务器返回的信息没有进行合适的验证和过滤,则可能存在服务器端请求伪造攻击。

服务器端请求伪造攻击场景如下图所示:

【挖掘笔记】web应用安全测试之业务漏洞


攻击者想要访问主机B上的服务,由于存在防火墙的原因无法直接访问,这时可以借助主机A来发起服务器端请求伪造攻击,通过主机A向主机B发起请求,从而完成攻击。

1SSRF攻击方式主要有以下5种:
2
3对外网、服务器所在内网、本地进行端口扫描,获取一些服务的banner信息(一般包括服务器的类型、版本,服务器上启动的服务信息);
4攻击运行在内网或本地的应用程序(比如堆栈溢出); 3) 通过访问默认文件实现对内网Web应用的指纹识别;
5攻击内外网的Web应用,主要是使用GET参数就可以实现的攻击(比如Struts2,Sqli等);
6利用file协议读取本地文件等。


风险等级:

【高危】:有回显,可探测内网,文件访问

【中危】:无回显,但可访问外网


修复方案

通常从以下几点来防御服务器端请求伪造攻击:

1过滤内网服务器对公网服务器请求的响应。如果Web应用是获取某一类型的文件,在把返回结果展示给用户之前应先验证返回的信息是否符合文件类型标准,比如返回信息应为图片,如果返回信息是HTML,则停止将返回信息返回客户端。
2统一错误提示信息,避免用户可以根据错误信息来判断远端服务器的端口状态。
3在内网服务器的防火墙上限制公网服务器的请求端口为HTTP等协议常用端口,如:8044380808090
4若公网服务器的内网IP与内网无业务通信,建议将公网服务器对应的内网IP列入黑名单,避免应用被用来获取内网数据。
5内网服务器禁用不必要的协议,仅允许HTTP和HTTPS请求,防止类似于file:///、gopher://、ftp:// 等协议引起的安全问题。


短信内容可控


漏洞描述

短信内容可从客户端指定


测试方法

在客户端编辑任意短信内容,测试是否过滤特殊内容。


风险分析

攻击者可利用该漏洞,借助短信平台,编辑钓鱼短信发送给其他用户。


风险等级:

【高危】:短信内容可控,且接收人可任意指定

【中危】:短信内容可控,但接受人不可控


修复方案

建议在不影响业务的前提下,禁止客户端编辑短信内容。


邮件内容可控


漏洞描述

应用系统发送邮件的邮件内容可由客户端任意指定


测试方法

在客户端编辑任意邮件内容,测试是否过滤特殊内容。


风险分析

攻击者可利用该漏洞,借助邮件平台,编辑钓鱼邮件发送给其他用户。


风险等级:

【高危】:邮件内容可控,且收件人可任意指定

【中危】:邮件内容可控,但收件人地址不可控


修复方案

建议在不影响业务的前提下,禁止客户端编辑邮件内容。


请求重放攻击


漏洞描述

关键业务操作未作token或者唯一标识码,导致攻击者可以重复多次进行请求,导致恶意操作。如重复交易等问题。


测试方法

重放http/tcp请求,查看第二次请求是否被正常处理。


风险分析

攻击者恶意或欺诈性地重复发送一个有效的数据包,如果服务器未检查此类重复提交的请求数据的有效性,那么转账充值等敏感操作将有可能会被重复执行。


风险等级:

【高危】:关键业务操作请求未设置 token 或标识码,导致业务数据越界或错误


修复方案

服务端应用程序应检查客户端提交的数据的唯一性,如使用流水号、时间戳、token等,并将流水号、时间戳等进行签名。


批量提交


漏洞描述

应用程序未使用验证码等防自动化操作的方法,可批量提交请求,如批量注册。


测试方法:

编写自动提交HTTP数据包的脚本;

或使用burpsuite的intruder功能批量提交请求。


风险分析

注册不需要验证码时,攻击者通过编写自动化脚本,实现程序自动提交注册信息;

若注册需要验证码,但验证码位数不多于4位且为纯数字时,通过使用软件burpsuite的intruder功能穷举得到正确的验证码后,再结合自动化脚本工具即可实现批量注册垃圾账号。


风险等级:

【高危】:正常业务为单条数据请求,且不存在防自动化批量操作措施,可批量自动化提交。

【低危】:正常业务为单条数据请求,且存在防自动化批量操作措施,但在单个数据包中写入批量数据,可成功提交,并且服务器能批量执行。


修复方案:

1.使用安全性强的验证码,验证码应从以下方面保证其安全性:验证码长度不低于4位,避免使用容易被程序自动识别的验证码,验证码不应返回客户端。

2.用户注册功能处,提交注册信息后进行邮箱或短信验证通过后再将注册信息写入数据库。

3.对同一IP地址短时间内提交请求的次数进行限制。


摘抄

在这烟尘人间,

并非俗不可耐索然无味,

冬日暖阳,夏日蝉鸣都显可爱。

【挖掘笔记】web应用安全测试之业务漏洞

版权声明:本文为CSDN博主「星球守护者」的原创文章,遵循CC 4.0 BY-SA版权协议,转载请附上原文出处链接及本声明。

原文链接:https://blog.csdn.net/qq_41901122/article/details/110877313

版权声明:著作权归作者所有。如有侵权请联系删除


开源聚合网安训练营

战疫期间,开源聚合网络安全基础班、实战班线上全面开启,学网络安全技术、升职加薪……有兴趣的可以加入开源聚合网安大家庭,一起学习、一起成长,考证书求职加分、升级加薪,有兴趣的可以咨询客服小姐姐哦!

【挖掘笔记】web应用安全测试之业务漏洞

加QQ(1005989737)找小姐姐私聊哦



精选文章


环境搭建
Python
学员专辑
信息收集
CNVD
安全求职
渗透实战
CVE
高薪揭秘
渗透测试工具
网络安全行业
神秘大礼包
基础教程
我们贴心备至
用户答疑
 QQ在线客服
加入社群
QQ+微信等着你

【挖掘笔记】web应用安全测试之业务漏洞


我就知道你“在看”
【挖掘笔记】web应用安全测试之业务漏洞


原文始发于微信公众号(开源聚合网络空间安全研究院):【挖掘笔记】web应用安全测试之业务漏洞

特别标注: 本站(CN-SEC.COM)所有文章仅供技术研究,若将其信息做其他用途,由用户承担全部法律及连带责任,本站不承担任何法律及连带责任,请遵守中华人民共和国安全法.
  • 我的微信
  • 微信扫一扫
  • weinxin
  • 我的微信公众号
  • 微信扫一扫
  • weinxin
admin
  • 本文由 发表于 2022年1月5日16:35:50
  • 转载请保留本文链接(CN-SEC中文网:感谢原作者辛苦付出):
                  【挖掘笔记】web应用安全测试之业务漏洞 http://cn-sec.com/archives/718982.html

发表评论

匿名网友 填写信息

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen: