{"id":10735,"date":"2017-12-06T09:10:07","date_gmt":"2017-12-06T17:10:07","guid":{"rendered":"http:\/\/www.palada.net\/index.php\/2017\/12\/06\/news-4507\/"},"modified":"2017-12-06T09:10:07","modified_gmt":"2017-12-06T17:10:07","slug":"news-4507","status":"publish","type":"post","link":"http:\/\/www.palada.net\/index.php\/2017\/12\/06\/news-4507\/","title":{"rendered":"How to harden AdwCleaner&#8217;s web backend using PHP"},"content":{"rendered":"<p><strong>Credit to Author: J\u00e9r\u00f4me Boursier| Date: Wed, 06 Dec 2017 16:00:28 +0000<\/strong><\/p>\n<p>More and more applications are moving from desktop to the web, where they are particularly exposed to security risks. They are often tied to a database backend, and thus need to be properly secured, even though most of the time they are designed to restrict access to authenticated users only. PHP is used to develop a lot of these web applications, including several dedicated to <a href=\"https:\/\/malwarebytes.com\/adwcleaner\" target=\"_blank\" rel=\"noopener\">AdwCleaner<\/a> management.<\/p>\n<p>There is no magic unique solution to harden a web application, but as always in security, it&#8217;s <a href=\"https:\/\/www.malwarebytes.com\/why-us\/\" target=\"_blank\" rel=\"noopener\">a matter of layers<\/a> including:<\/p>\n<ul>\n<li>Applying the latest security patch and updates<\/li>\n<li>Sending the correct HTTP headers<\/li>\n<li>Hardening the language stack<\/li>\n<li>Hardening the OS<\/li>\n<li>Taking network security measures<\/li>\n<\/ul>\n<p>Since we&#8217;re in 2017, we&#8217;ll consider that security patches and updates are applied properly so this article will focus on several must-have HTTP headers, as well as how we harden our web stack at a PHP level in an effective and easy way for the AdwCleaner web management application.<\/p>\n<h3>Securing a web application using HTTP headers<\/h3>\n<p>There are a lot of standard HTTP headers for various uses (like encoding and caching) and a lot of them aim to enforce smart security behaviors,\u00a0like mitigating <a href=\"https:\/\/www.owasp.org\/index.php\/Cross-site_Scripting_(XSS)\">XSS,<\/a>\u00a0for HTTP clients (i.e web browsers). Here are a few useful ones.<\/p>\n<div id=\"attachment_20737\" style=\"width: 610px\" class=\"wp-caption aligncenter\"><img loading=\"lazy\" decoding=\"async\" class=\"size-large wp-image-20737\" src=\"https:\/\/blog.malwarebytes.com\/wp-content\/uploads\/2017\/12\/xss-600x330.png\" alt=\"XSS vulnerability example\" width=\"600\" height=\"330\" srcset=\"https:\/\/blog.malwarebytes.com\/wp-content\/uploads\/2017\/12\/xss-600x330.png 600w, https:\/\/blog.malwarebytes.com\/wp-content\/uploads\/2017\/12\/xss-300x165.png 300w\" sizes=\"auto, (max-width: 600px) 100vw, 600px\" \/><\/p>\n<p class=\"wp-caption-text\">A website suffering of XSS, without the proper HTTP headers in place to mitigate it.<\/p>\n<\/div>\n<h4>Strict-Transport-Security<\/h4>\n<p>This instructs the browser to connect to the website using HTTPS directly for a certain period of time using the <em>max-age<\/em> directive. It can also be applied to subdomains with <em>includeSubDomains<\/em> directive.<\/p>\n<ul>\n<li><a href=\"https:\/\/www.owasp.org\/index.php\/HTTP_Strict_Transport_Security_Cheat_Sheet\" target=\"_blank\" rel=\"noopener\">OWASP cheat sheet about XSS<\/a><\/li>\n<\/ul>\n<h4>Referrer-Policy<\/h4>\n<p>This header aims to have a fine-grained control over when the referrer is transmitted. Several directives are available, from <em>no-referrer<\/em> to completely disable the referrer header to <em>strict-origin-when-cross-origin<\/em>, which means that the full URL is sent with any request made in TLS in the same domain. (Whereas only the domain is sent as referrer if the request is made on a different domain or subdomain.) Finally, if the request is made in HTTP, the referrer is not sent.<\/p>\n<p>It&#8217;s a handy header especially to reduce internal URL leaks to external services.<\/p>\n<ul>\n<li><a href=\"https:\/\/wiki.mozilla.org\/Security\/Guidelines\/Web_Security#Referrer_Policy\" target=\"_blank\" rel=\"noopener\">Mozilla Documentation<\/a><\/li>\n<\/ul>\n<h4>X-Content-Type-Option<\/h4>\n<p>It enforces the MIME type of resources, and states that they shouldn&#8217;t be changed. If the MIME type is not the one advertised with the Content-Type header, then the request is dropped in order to mitigate MIME confusion attacks. There&#8217;s only one directive:\u00a0<em>nosniff<\/em>.<\/p>\n<p><a href=\"http:\/\/: https:\/\/developer.mozilla.org\/en-US\/docs\/Web\/HTTP\/Headers\/X-Content-Type-Options\" target=\"_blank\" rel=\"noopener\">Mozilla Documentation<\/a><\/p>\n<h4>X-Frame-Options<\/h4>\n<p>This header controls whether or not the page can be loaded as an iframe or an object. There are different directives, from <em>DENY<\/em> to forbid this behaviour, to <em>SAMEORIGIN,<\/em> which allows it only from the same origin (domain or subdomain), and <em>ALLOW-FROM<\/em> which allows the operator to specify a whitelist of origins.<\/p>\n<p><a href=\"http:\/\/tools.ietf.org\/html\/7034\" target=\"_blank\" rel=\"noopener\">RFC 7034<\/a><\/p>\n<h4>X-Robots-Tag<\/h4>\n<p>This controls how the page should be handled by crawling bots (i.e search engines). Several directives exist: the <em>noindex, nofollow, nosnippet, noarchive<\/em> directives will avoid the page to be indexed in search results and instruct the crawler to not follow the links of the page. The crawler will also not store any copy of the page.<\/p>\n<p><a href=\"https:\/\/developers.google.com\/search\/reference\/robots_meta_tag\" target=\"_blank\" rel=\"noopener\">Google documentation<\/a><\/p>\n<h4>X-XSS-Protection<\/h4>\n<p>This legacy header instructs the browser to block any detected XSS request when set to <em>1; mode=block<\/em>. It&#8217;s now superseded by the Content-Security-Policy header, but is still useful on older web browsers. This header would have mitigated the XSS on the website at the beginning of this article.<\/p>\n<h4>Content-Security-Policy<\/h4>\n<p>This powerful header allows the operator to define rules specifying how the webpage resources can be loaded and where from. It&#8217;s particularly efficient against XSS. For instance, it&#8217;s possible to enforce loading resources on HTTPS only using\u00a0<em>default-src: https:<\/em>, or to forbid any inline scripts with the directive <em>default-src: &#8216;unsafe-inline&#8217;<\/em>.<\/p>\n<p>It&#8217;s possible to create more complex rules, for instance:<\/p>\n<p><em>base-uri &#8216;none&#8217;;<\/em>\u00a0 Forbid the usage &lt;base&gt; URI.<br \/> <em>default-src &#8216;self&#8217;;<\/em>\u00a0Will use the origin as fallback for any fetch directive which is not specified.<br \/> <em>frame-src;<\/em> forbid any external content to be loaded using iframes.<br \/> <em>connect-src &#8216;self&#8217;;<\/em>\u00a0Forbid ping, Fetch, XMLHttpRequest, WebSocket, and EvenSource to load external content.<br \/> <em>form-action &#8216;self&#8217;;<\/em>\u00a0Enforce the forms submissions to the origin.<br \/> <em>frame-ancestors &#8216;none&#8217;;<\/em> As X-Frame-Options: Deny, it forbids loading the page using iframes, objects, embed, or applets.<br \/> <em>img-src &#8216;self&#8217; data:;<\/em> Allow &lt;img&gt; tags to use data uris from the origin only.<br \/> <em>media-src &#8216;none&#8217;;\u00a0<\/em> Forbid loading any &lt;audio&gt; or &lt;video&gt; elements.<br \/> <em>object-src &#8216;none&#8217;;<\/em> Forbid loading any &lt;object&gt;, &lt;embed&gt;, and &lt;applet&gt; elements.<br \/> <em>script-src &#8216;self&#8217; &#8216;unsafe-inline&#8217;;<\/em> Javascript can be loaded inline from the origin only.<br \/> <em>style-src &#8216;self&#8217; &#8216;unsafe-inline&#8217;;<\/em> Stylesheets can be loaded inline from the origin only.<br \/> <em>report-uri \/csp-report;<\/em> Instruct the client to POST any violation of the policy to the specified address, here <em>https:\/\/domain.com\/csp-report<\/em>. This directive is being replaced by <em>report-to<\/em> which has the same syntax.<\/p>\n<p>Here are the W3C specifications about <a href=\"https:\/\/www.w3.org\/TR\/CSP2\/\" target=\"_blank\" rel=\"noopener\">CSP level 2<\/a> and<em><strong><a href=\"https:\/\/www.w3.org\/TR\/CSP3\/\" target=\"_blank\" rel=\"noopener\"> CSP3<\/a>.<\/strong><\/em><\/p>\n<p>While deploying all of these headers may seem difficult, the only read head-scratcher is\u00a0<em>Content-Security-Policy.<\/em> Although this one <strong>must<\/strong> be deployed, it should be done <strong>with care<\/strong> as it may break a lot of applications easily. Use\u00a0<a href=\"https:\/\/csp-evaluator.withgoogle.com\" target=\"_blank\" rel=\"noopener\">Google Evaluator<\/a>, a handy tool to analyze any website CSP.<\/p>\n<p>Another valuable service is <a href=\"https:\/\/securityheaders.io\/\" target=\"_blank\" rel=\"noopener\">SecurityHeaders.io<\/a>, which test your web application headers and give some advice when some are missing or misconfigured.<\/p>\n<p>Here are a few configuration snippets for three webservers to deploy the above configuration. Please note that you may need to adapt this configuration depending on your specific needs (especially the CSP):<\/p>\n<ul>\n<li><a href=\"http:\/\/nginx.org\/en\/\" target=\"_blank\" rel=\"noopener\">Nginx<\/a><\/li>\n<\/ul>\n<pre><code class=\"language-python\">add_header Strict-Transport-Security \"max-age=31536000; includeSubdomains; preload\";  add_header 'Referrer-Policy' 'same-origin';  add_header X-Content-Type-Options nosniff;  add_header X-Frame-Options SAMEORIGIN;  add_header X-Robots-Tag \"noindex, nofollow, nosnippet, noarchive\";  add_header X-XSS-Protection \"1; mode=block\";  add_header Content-Security-Policy \"base-uri 'none'; default-src 'self'; child-src;connect-src 'self'; form-action 'self'; frame-ancestors 'none'; img-src 'self' data:; media-src 'none'; object-src 'none'; script-src 'self' 'unsafe-inline'; style-src 'self' 'unsafe-inline'; report-uri \/csp-report; report-to \/csp-report;\"<\/code><\/pre>\n<ul>\n<li><a href=\"https:\/\/caddyserver.com\/\" target=\"_blank\" rel=\"noopener\">Caddy<\/a><\/li>\n<\/ul>\n<pre><code class=\"language-python\">header \/ {      Strict-Transport-Security \"max-age=31536000; includeSubdomains; preload\"      Referrer-Policy 'same-origin'      X-Content-Type-Options nosniff      X-Frame-Options SAMEORIGIN      X-Robots-Tag \"noindex, nofollow, nosnippet, noarchive\"      X-XSS-Protection \"1; mode=block\"      Content-Security-Policy \"base-uri 'none'; default-src 'self'; child-src;connect-src 'self'; form-action 'self'; frame-ancestors 'none'; img-src 'self' data:; media-src 'none'; object-src 'none'; script-src 'self' 'unsafe-inline'; style-src 'self' 'unsafe-inline'; report-uri \/csp-report; report-to \/csp-report;\"  }<\/code><\/pre>\n<ul>\n<li><a href=\"https:\/\/httpd.apache.org\/\" target=\"_blank\" rel=\"noopener\">Apache<\/a><\/li>\n<\/ul>\n<pre><code class=\"language-python\">Header always set Strict-Transport-Security \"max-age=31536000; includeSubdomains; preload\"  Header always set Referrer-Policy 'same-origin'  Header always set X-Content-Type-Options nosniff  Header always set X-Frame-Options SAMEORIGIN  Header always set X-Robots-Tag \"noindex, nofollow, nosnippet, noarchive\"  Header always set X-XSS-Protection \"1; mode=block\"  Header always set Content-Security-Policy \"base-uri 'none'; default-src 'self'; child-src;connect-src 'self'; form-action 'self'; frame-ancestors 'none'; img-src 'self' data:; media-src 'none'; object-src 'none'; script-src 'self' 'unsafe-inline'; style-src 'self' 'unsafe-inline'; report-uri \/csp-report; report-to \/csp-report;\"  <\/code><\/pre>\n<p>While setting the correct security HTTP headers is a good first step to mitigate some attacks, it&#8217;s not sufficient.<\/p>\n<p>That&#8217;s why AdwCleaner&#8217;s backend PHP stack is also hardened to higher the cost of exploiting vulnerabilities.<\/p>\n<h3>Hardening PHP<\/h3>\n<p>The problem we&#8217;re trying to solve is to restrict the language surface that the application can access to:<\/p>\n<ul>\n<li>block access to specific functions.<\/li>\n<li>give access only to a restricted set of files and classes.<\/li>\n<li>sanitize various functions inputs.<\/li>\n<li>restrict execution to read-only PHP files and deny it on writable ones.<\/li>\n<li>replace <em>rand()<\/em> and <em>mt_rand()<\/em> by <em>random_int()<\/em>.<\/li>\n<\/ul>\n<p>This may sound simple, but it becomes quickly complex to manage at large scale, especially without tinkering with the application source code.<\/p>\n<p>Since we&#8217;re in 2017, we use PHP7, meaning that we cannot use <a href=\"https:\/\/www.suhosin.org\/stories\/index.html\" target=\"_blank\" rel=\"noopener\">Suhosin<\/a> any longer, as it&#8217;s only working with PHP5 and below. We&#8217;re not alone in this situation. Thus,\u00a0<a href=\"https:\/\/github.com\/nbs-system\/snuffleupagus\/graphs\/contributors\" target=\"_blank\" rel=\"noopener\">some fine people<\/a> developed <a href=\"https:\/\/github.com\/nbs-system\/snuffleupagus\" target=\"_blank\" rel=\"noopener\">Snuffleupagus<\/a>, a PHP7+ extension that takes a lot of inspiration from Suhosin but with extended capacities and a more industrialized usage.<\/p>\n<div id=\"attachment_20739\" style=\"width: 266px\" class=\"wp-caption aligncenter\"><img loading=\"lazy\" decoding=\"async\" class=\"wp-image-20739 size-full\" src=\"https:\/\/blog.malwarebytes.com\/wp-content\/uploads\/2017\/12\/sp.png\" alt=\"Snuffleupagus logo - an elephant as majestic as php itself\" width=\"256\" height=\"257\" srcset=\"https:\/\/blog.malwarebytes.com\/wp-content\/uploads\/2017\/12\/sp.png 256w, https:\/\/blog.malwarebytes.com\/wp-content\/uploads\/2017\/12\/sp-150x150.png 150w\" sizes=\"auto, (max-width: 256px) 100vw, 256px\" \/><\/p>\n<p class=\"wp-caption-text\">Snuffleupagus logo &#8211; an elephant as majestic as PHP itself<\/p>\n<\/div>\n<p>Snuffleupagus mitigates issues in two main ways:<\/p>\n<ul>\n<li><a href=\"https:\/\/snuffleupagus.readthedocs.io\/config.html#bugclass-killer-features\" target=\"_blank\" rel=\"noopener\">Kill bug classes<\/a> at once<\/li>\n<li><a href=\"https:\/\/snuffleupagus.readthedocs.io\/config.html#virtual-patching\" target=\"_blank\" rel=\"noopener\">Patch PHP functions<\/a><\/li>\n<\/ul>\n<p>Killing bug classes at once is pretty handy: Instead of writing a rule for every situation, it&#8217;s possible to write a generic rule which will mitigate numerous bugs. For instance, <em>mail()<\/em> RCE, weak PRNG, permissive <em>chmod()<\/em> , system injections, or file upload RCE can be easily fixed using only one or two rules to address the whole bug family.<\/p>\n<p>A practical example using file-upload RCE:<\/p>\n<pre><code class=\"language-php\">$uploaddir = '\/var\/www\/uploads\/';  $uploadfile = $uploaddir . basename($_FILES['userfile']['name']);  move_uploaded_file($_FILES['userfile']['tmp_name'], $uploadfile)<\/code><\/pre>\n<p>This gives countless RCEs (CVE-2001-1032, CVE-2016-9187&#8230;). It&#8217;s possible to mitigate it using the following directive:<\/p>\n<pre><code class=\"language-php\">sp.upload_validation.script(\"tests\/upload_validation.sh\").enable();<\/code><\/pre>\n<p>Where the file <em>tests\/upload_validation.sh<\/em> contains:<\/p>\n<pre><code class=\"language-bash\">$ php -d vld.execute=0 -d vld.active=1 -d extension=vld.so $file<\/code><\/pre>\n<p>That way any upload containing PHP code will be dropped.<\/p>\n<p>Another feature valuable for our use case is virtual patching. It allows fine-grained settings for functions. For instance, I want to allow a call to <em>system(&#8220;id&#8221;)<\/em> but I don\u2019t want to allow any other <em>system<\/em> calls. The rules would look like:<\/p>\n<pre><code class=\"language-php\">sp.disable_functions.function(\"system\").param(\"cmd\").value(\"id\").allow();  sp.disable_functions.function(\"system\").param(\"cmd\").drop();  <\/code><\/pre>\n<p>Since the rules are evaluated in order, we first allow a call to <em>system<\/em> with <em>id<\/em> as the <em>cmd<\/em> argument, and we then drop all other rules.<\/p>\n<p>It\u2019s also possible to write rules for a specific filename (<code>filename(name)<\/code>), hash (<em>hash(sha256)<\/em>), return value (<em>ret(value)<\/em>) or type (<em>ret_type(type_name)<\/em>), and client ip (<em>cidr(ip\/mask)<\/em>). Also, the behaviour can be adapted. If it triggers a rule:<\/p>\n<ul>\n<li><em>drop()<\/em>: drop the request<\/li>\n<li><em>simulation()<\/em>: only log the event without blocking it<\/li>\n<li><em>allow()<\/em>: allow the request<\/li>\n<li><em>dump()<\/em>: dump the request in a directory<\/li>\n<\/ul>\n<p>An entry in the PHP logfile is written when an event is triggered, for instance:<\/p>\n<pre><code class=\"language-php\">2017\/10\/08 07:30:19 [error] 625#625: *54641 FastCGI sent in stderr: \"PHP message: [snuffleupagus][0.0.0.0][include][drop]  Inclusion of a forbidden file (\/a\/path\/to\/a\/webroot\/..\/..\/..\/)\" while reading response header from upstream,  client: &lt;redacted&gt;, server: adwcleaner.example.com, request: \"GET \/ HTTP\/2.0\", upstream: \"fastcgi:\/\/unix:\/var\/run\/php\/php7.0-fpm.sock:\", host: \"adwcleaner.example.com\"  <\/code><\/pre>\n<p>Since no one likes writing rules by hand, a nice way to start is by using <a href=\"https:\/\/github.com\/nbs-system\/snuffleupagus\/blob\/master\/scripts\/generate_rules.php\" target=\"_blank\" rel=\"noopener\">a script<\/a>\u00a0that parses the application PHP files, computes the hash of functions containing <em>dangerous<\/em> functions, and generates rules based on the results\u2014only the files with the corresponding hashes will be allowed to execute these functions.<\/p>\n<p>We generate new customized rules at every update pushed in production, alongside a set of default rules that are always valid (like system calls, uploads validation, and read-only execution). Since the log format is easy enough to parse, we can trigger notifications when a request has been blocked by one of the rules and act accordingly:<\/p>\n<div id=\"attachment_20738\" style=\"width: 348px\" class=\"wp-caption aligncenter\"><img loading=\"lazy\" decoding=\"async\" class=\"size-large wp-image-20738\" src=\"https:\/\/blog.malwarebytes.com\/wp-content\/uploads\/2017\/12\/alerting-338x600.jpeg\" alt=\"Snuffleupagus - email alerting\" width=\"338\" height=\"600\" srcset=\"https:\/\/blog.malwarebytes.com\/wp-content\/uploads\/2017\/12\/alerting-338x600.jpeg 338w, https:\/\/blog.malwarebytes.com\/wp-content\/uploads\/2017\/12\/alerting-169x300.jpeg 169w, https:\/\/blog.malwarebytes.com\/wp-content\/uploads\/2017\/12\/alerting.jpeg 1080w\" sizes=\"auto, (max-width: 338px) 100vw, 338px\" \/><\/p>\n<p class=\"wp-caption-text\">Mail notification sent when a snuffleupagus rule has been triggered.<\/p>\n<\/div>\n<p>&nbsp;<\/p>\n<p>The documentation is available on <a href=\"http:\/\/snuffleupagus.readthedocs.io\" target=\"_blank\" rel=\"noopener\">ReadTheDocs<\/a> along <a href=\"http:\/\/snuffleupagus.readthedocs.io\/papers.html\" target=\"_blank\" rel=\"noopener\">with slides<\/a> from their talk at BerlinSide, Hack.lu, and BlackAlps.<\/p>\n<h3>Conclusion<\/h3>\n<p>This article covered only two of the multiple measures we take to secure <a href=\"https:\/\/malwarebytes.com\/adwcleaner\" target=\"_blank\" rel=\"noopener\">AdwCleaner<\/a>&#8216;s backend. Although some of these vulnerabilities can be mitigated client-side using browsers add-ons like <a href=\"https:\/\/addons.mozilla.org\/en-US\/firefox\/addon\/noscript\/\" target=\"_blank\" rel=\"noopener\">NoScript<\/a>, it&#8217;s always better to fix them as soon as possible using the easy techniques explained above. More hardening can be done at the OS and network level, and you can refer to <a href=\"https:\/\/blog.malwarebytes.com\/security-world\/2017\/06\/https-everywhere\/\" target=\"_blank\" rel=\"noopener\">our previous article about TLS<\/a> to learn more about some of these.<\/p>\n<p>The post <a rel=\"nofollow\" href=\"https:\/\/blog.malwarebytes.com\/security-world\/technology\/2017\/12\/harden-adwcleaner-php-web-backend\/\">How to harden AdwCleaner&#8217;s web backend using PHP<\/a> appeared first on <a rel=\"nofollow\" href=\"https:\/\/blog.malwarebytes.com\">Malwarebytes Labs<\/a>.<\/p>\n<p><a href=\"https:\/\/blog.malwarebytes.com\/security-world\/technology\/2017\/12\/harden-adwcleaner-php-web-backend\/\" target=\"bwo\" >https:\/\/blog.malwarebytes.com\/feed\/<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"<p><strong>Credit to Author: J\u00e9r\u00f4me Boursier| Date: Wed, 06 Dec 2017 16:00:28 +0000<\/strong><\/p>\n<table cellpadding='10'>\n<tr>\n<td valign='top' align='center'><a href='https:\/\/blog.malwarebytes.com\/security-world\/technology\/2017\/12\/harden-adwcleaner-php-web-backend\/' title='How to harden AdwCleaner's web backend using PHP'><img src='https:\/\/blog.malwarebytes.com\/wp-content\/uploads\/2017\/12\/phpsecure.jpg' border='0'  width='300px'  \/><\/a><\/td>\n<\/tr>\n<tr>\n<td valign='top' align='left'>More and more applications are moving from desktop to the web, where they are particularly exposed to security risks. They are often tied to a database backend, and thus need to be properly secured, even though most of the time they are designed to restrict access to authenticated users only. PHP is used to develop&#8230;<\/p>\n<p>Categories: <\/p>\n<ul class=\"post-categories\">\n<li><a href=\"https:\/\/blog.malwarebytes.com\/category\/security-world\/\" rel=\"category tag\">Security world<\/a><\/li>\n<li><a href=\"https:\/\/blog.malwarebytes.com\/category\/security-world\/technology\/\" rel=\"category tag\">Technology<\/a><\/li>\n<\/ul>\n<p>Tags: <a href=\"https:\/\/blog.malwarebytes.com\/tag\/adwcleaner\/\" rel=\"tag\">AdwCleaner<\/a><a href=\"https:\/\/blog.malwarebytes.com\/tag\/cybersecurity\/\" rel=\"tag\">cybersecurity<\/a><a href=\"https:\/\/blog.malwarebytes.com\/tag\/header\/\" rel=\"tag\">header<\/a><a href=\"https:\/\/blog.malwarebytes.com\/tag\/http\/\" rel=\"tag\">http<\/a><a href=\"https:\/\/blog.malwarebytes.com\/tag\/php\/\" rel=\"tag\">php<\/a><a href=\"https:\/\/blog.malwarebytes.com\/tag\/website\/\" rel=\"tag\">website<\/a><a href=\"https:\/\/blog.malwarebytes.com\/tag\/xss\/\" rel=\"tag\">xss<\/a><\/p>\n<table width='100%'>\n<tr>\n<td align=right>\n<p><b>(<a href='https:\/\/blog.malwarebytes.com\/security-world\/technology\/2017\/12\/harden-adwcleaner-php-web-backend\/' title='How to harden AdwCleaner's web backend using PHP'>Read more&#8230;<\/a>)<\/b><\/p>\n<\/td>\n<\/tr>\n<\/table>\n<\/td>\n<\/tr>\n<\/table>\n<p>The post <a rel=\"nofollow\" href=\"https:\/\/blog.malwarebytes.com\/security-world\/technology\/2017\/12\/harden-adwcleaner-php-web-backend\/\">How to harden AdwCleaner&#8217;s web backend using PHP<\/a> appeared first on <a rel=\"nofollow\" href=\"https:\/\/blog.malwarebytes.com\">Malwarebytes Labs<\/a>.<\/p>\n","protected":false},"author":4,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"colormag_page_container_layout":"default_layout","colormag_page_sidebar_layout":"default_layout","footnotes":""},"categories":[10488,10378],"tags":[16857,4500,16858,16859,16860,10497,1331,12129,15775],"class_list":["post-10735","post","type-post","status-publish","format-standard","hentry","category-malwarebytes","category-security","tag-adwcleaner","tag-cybersecurity","tag-header","tag-http","tag-php","tag-security-world","tag-technology","tag-website","tag-xss"],"_links":{"self":[{"href":"http:\/\/www.palada.net\/index.php\/wp-json\/wp\/v2\/posts\/10735","targetHints":{"allow":["GET"]}}],"collection":[{"href":"http:\/\/www.palada.net\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/www.palada.net\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/www.palada.net\/index.php\/wp-json\/wp\/v2\/users\/4"}],"replies":[{"embeddable":true,"href":"http:\/\/www.palada.net\/index.php\/wp-json\/wp\/v2\/comments?post=10735"}],"version-history":[{"count":0,"href":"http:\/\/www.palada.net\/index.php\/wp-json\/wp\/v2\/posts\/10735\/revisions"}],"wp:attachment":[{"href":"http:\/\/www.palada.net\/index.php\/wp-json\/wp\/v2\/media?parent=10735"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/www.palada.net\/index.php\/wp-json\/wp\/v2\/categories?post=10735"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/www.palada.net\/index.php\/wp-json\/wp\/v2\/tags?post=10735"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}