The latest from Blogger Buzz

Keep your readers interested with the AdSense Guide to Audience Engagement

Today, information is at our fingertips and we can access it from anywhere on any device. Just a few taps pull up millions of websites all competing for our attention. For bloggers, engaging with your audience has never been more important or more challenging. To help lay the foundation to a winning engagement strategy, the AdSense team created the AdSense Guide to Audience Engagement.

Research shows that 29% of smartphone users will immediately switch to another site or app if it doesn’t satisfy their needs.

To help keep your audience engaged, get your free copy of the AdSense Guide to Audience Engagement.
In the guide, you’ll learn:
  • How to help your audience become familiar with your brand
  • Best practices to design user journeys
  • How to develop content that resonates with your audience
  • Ways to make your content easy to consume
  • Why you should share the love with other sites by referring to good sources


If you are looking send a very personal or important file which you want destroyed after the receiver sees/reads it, you can now avail the services of a website called Nafue. [menkveldj]who is a developer, has built a service that encrypts files which self destruct in 24 hours.
However there some many prerequisites for using a the website. The download link can only be used once.
Nafue works like this. You want to share a very imported file, you have to encrypt it on your side using a a password generated using Pbkdf2 key before uploading it to the s3 storage service. Once this is done, the website will provide you with a one-time-use link to share with the recipient. After the first download, or 24 hours, the link and the encrypted file are both deleted.
Remember, the receiver must enter the same password to decrypt and recover the file. No one but the sharer and receiver know what the actual file is.
If the file were to land in some wrong person’s hand, they would take some years before cracking the 256AES encryption.
It’s still work in progress, so chime in with your comments and suggestions. To dig into the code, check out his repository on Github, which also has instructions to build and run it if you’d like to do your own version.

Short Bytes: A Web App Attack is one of the biggest threats faced by websites and online businesses. In this article, we are going to tell you about 5 stages of a Web App Attack — Reconnaissance, Scanning, Gaining Access, Maintaining Access, and Covering Tracks — and how this attack works.
If we start looking at the number of hacking attacks in 2015 alone, the number of personal records breached touches almost one billion. In 2015, we saw some of the most notorious hacking attacks till date, namely attacks on Ashleey MadisonTalkTalkPatreon Donation SitePentagonetc.
As the application development is moving more and more onto the web, the Web is home to everything we need. 2015 also saw an increase in Web App Attacks that are carried out using a well-planned plan-of-action. The attack usually targets the web server used by the target company. In spite of network defenses like intrusion penetration systems and firewalls, the Web application could be attacked by an outsider in multiple ways.

What Is A Web App Attack, How Does It Work

In this article, we are going to explain you the five stages of a Web App Attack from a hacker’s perspective. The each stage will be explained into three parts — What is it? How does it work? How do I defend myself against it?
The five stages that will be explained ahead are: Reconnaissance, Scanning, Gaining Access, Maintaining Access, and Covering Tracks.
Let’s take a look at this useful infographic by Barricade, an Early Warning System against Hackers.

Anatomy of a Web App Attack – Visually Explained


This Government of Canada press release caught my eye on a recent newsfeed. The release tells the story of how PING could save and prevent accidents. It’s one of those reports that uses language which for most of us is completely unintelligible or steeped in scientific nuance. So let me break it down for you: a train fell off the tracks and PING could have stopped it.
Hold on, how can something as simple as an Internet Control Message Protocol (ICMP) packet save lives? The reality is actually kind of obvious in this world of Internet of things (IoT) – latency. Using this analogy, the number of seconds or milliseconds it takes for a packet of data to go from one place or another could have prevented this train from being derailed. If there is a change in the latency, there is a problem on the tracks. Yes, my friends, PING works on rail tracks, which in a way are like giant cables reaching out across the nations.
This fact got me thinking. PING is one of the most basic of IT functions. The PING check is built into almost every Remote Monitoring and Management Tool (RMM) on the market today, including our own MAXfocus platform. However, this story is not about our great products, it’s about how PING could have mitigated a train derailment – it blows my mind that all of sudden ICMP becomes the deciding factor between business-as-usual and disaster.
If you can accept the idea that the railway is like a big, conductive pipe and has a TCIP stack, you can accept the idea that a simple PING could tell you a lot about the quality of transmission. The intimate relationship between PING and the quality of the Layer 1 – i.e. the physical layer – is well known: bad cable equals latency and dropped packets. If you’ve sent thousands or hundreds of thousands of PINGS you would know what the average response time should be.
When the response time is radically different or there is no response; then you know you have a problem. But surely life is not that simple? Oddly with PING, it really is. One of the first things a helpdesk does (after making you reboot) is to ask you to PING the router/IP you need to get to. If you can’t “see” it, you have a connection problem.
Understanding this is going to be key to understanding the IoT. PING will become, if it is not already, one of the default troubleshooting protocols/services we will use to figure out connectivity. If PING does not return, there is a problem. It’s astounding to me that we still have problems understanding this concept.
We live in a world where has to answer to a PING if it does not some folks would suggest we will all die, or at the very least our websites will load really slowly. PING is not DNS, it’s not even Https, it’s lower level and it’s what we use to determine – in IT terms – if you are alive or not. There are lots of folks that turn PING off on their outside interface because of the PING of death, which caused so many problems back in the day, but if you’re still running a firewall that can’t handle a packet outside of an RFC spec you have other much more serious problems.
But I digress. I said PING will save us and I meant it. We have big data – LOGICcards is an example of that – but how cool would it be if your PING check worked across all of the customers?
Imagine if our 2 million endpoints could tell you the expected PING time to important websites and if your customer’s PING time was outside that. No one will ever complain about too fast, but the phones light up if we’re too slow. How cool would that be?
So, how does this affect the IoT or rail cars traveling down the line? It’s simple. If PING gets too long, or there is no ECHO then stop the train, because something is not right. If something is not right it could mean a physical problem that could derail your train. It’s not a super technical thing – if it’s not ECHO’ing a reply it’s probably not online. If it’s not online and it needs to be you better go fix it.
PING may just save you a world of pain when and prevent your train – metaphorical or not –from going off the tracks.

Leaving your websites open to attack?

70% of websites and networks are hackable!
Close your doors shut before hackers find you

CSRF Attacks, XSRF or Sea-Surf – What They Are and How to Defend Against Them

Cross-Site Request Forgery, or CSRF for short is a common and regular online attack. CSRF also goes by the acronym XSRF and the phrase “Sea-Surf”. CSRF attacks include a malicious exploit of a website in which a user will transmit malicious requests that the target website trusts without the user’s consent. In Cross-Site Scripting (XSS), the attacker exploits the trust a user has for a website, with CSRF on the other hand, the attacker exploits the trust a website has against a user’s browser.
Basically, an attacker will use CSRF to trick a victim into accessing a website or clicking a URL link that contains malicious or unauthorized requests. It is called ‘malicious’ since the CSRF attack will use the identity and privileges of the victim and impersonate them in order to perform any actions desired by the attacker, such as change form submission details, and launch purchases or payments for the attacker or a third-party account.
Upon a request against most websites, browsers will include along any credentials related with the particular website, such as the session cookie of the user, basic authentication credentials, the IP address of the user, etc. Thus, if user’s authentication session is still valid, an attacker can use CSRF to launch any desired requests against the website, without the website being able to distinguish whether the requests are legitimate or not.

A Simple Example of a Cross-Site Request Forgery

As described above, in order for a CSRF attack to be performed, the user must be authenticated with the target website. Assuming the victim is authenticated, the attacker can include a link or script in a third-party website that the victim visits. Thus, when the victim visits that website or link, the rogue script will be executed without the victim being aware of it. For instance, in a chat forum, an attacker posts a message which contains an image tag or an HTML image element. However, the source of the image contains a link which performs an action on a victim’s bank website account. So, instead of an image file the attacker has included a link that performs a bank transaction. Below is an example of the image tag containing a rogue URL.
<img src="">
The above is a CSRF attack using an HTTP GET request. As we shall see later, a prevention method would allow only HTTP POST requests, in order to prevent the above attack method. However, this can be easily bypassed, since an attacker can use an HTTP POST request to perform a CSRF attack.

CSRF Example Using an HTTP POST Request

In this example the attacker will use an HTTP POST request to realize a CSRF attack. Since the HTTP GET request is not allowed to be used as a prevention measure against a CSRF attack, an attacker can use the HTTP POST request which will perform the CSRF as successfully as the HTTP GET request. It is very difficult for the target website to distinguish between legitimate and rogue HTTP GET or POST requests, since the requests are sent from a “trusted” browser. That means that if no prevention measures are in place, a CSRF attack can be performed transparently without the victim or target website realizing it.
The purpose of the attack, in this example, is to change the profile information of a particular user (victim) on the target website. The target website for this example will be
Target Website Example for CSRF Attack
The victim has an account on which includes personal information as seen below.
Example victim of CSRF attack
The attacker uses CSRF to change the information on the victim’s profile. This, as mentioned earlier, requires the victim to be authenticated with the target website. A user can update the profile information by using the given form in the ‘Your profile’ page. The code of the particular form is shown below.
CSRF Example in –
<form name="form1" method="post" action="">
<table border="0" cellspacing="1" cellpadding="4">
<td valign="top">Name:</td><td><input type="text" value="James Markus" name="urname" style="width:200px"></td>
<tr><td valign="top">Credit card number:</td><td><input type="text" value="1254-5498-5233-5569" name="ucc" style="width:200px"></td>
<tr><td valign="top">E-Mail:</td><td><input type="text" value="" name="uemail" style="width:200px"></td>
<tr><td valign="top">Phone number:</td><td><input type="text" value="+44 123 12345 123" name="uphone" style="width:200px"></td>
<tr><td valign="top">Address:</td><td><textarea wrap="soft" name="uaddress" rows="5" style="width:200px">North London, London, England</textarea></td>
<tr><td colspan="2" align="right"><input type="submit" value="update" name="update"></td></tr></table>
From the above code we can identify the input fields which will receive information from a user and send to the website. These are called urnameuccuemailuphone and uaddress and are shown below.
<input type="text" value="John Doe" name="urname" style="width:200px">
<input type="text" value="1254-5498-5233-5569" name="ucc" style="width:200px">
<input type="text" value="" name="uemail" style="width:200px">
<input type="text" value="+44 123 12345 123" name="uphone" style="width:200px">
<textarea wrap="soft" name="uaddress" rows="5" style="width:200px">
North London, London, England</textarea>
When the user clicks the ‘Update’ button of the form userinfo.php, an HTTP POST request will be sent that will contain the above parameters along with their values accordingly.
Since the website does not have any prevention measures against CSRF, the attacker can use this form ( to submit any desired information without the user’s consent. The attacker will perform this by embedding the actual code of the update form in his own website and when the victim visits the attacker’s website, the form, including any desired information of the attacker, will be submitted to the target website.
This is the malicious website of the attacker.
Example victim of CSRF attack
The attacker’s website is a normal online photo gallery website. However, it contains a hidden form which will auto submit and update the victim’s profile on
The hidden iframe exists in the myimages.php page.
<iframe src="" style="display:none"></iframe>
This loads another page of the attacker’s website. The website contains the actual userinfo.php page code which auto submits and updates the particular userinfo.php of the current victim. This happens automatically every time a user accesses this website.
The updateif.php page contains the actual form code which auto submits the desired information the attacker has set.

<body onload="document.getElementById('f').submit()">
<form id="f" action="" method="post" name="form1">
<input name="urname" value="attacker’svalue">
<input name="ucc" value=" attacker’svalue">
<input name="uemail" value=" attacker’svalue">
<input name="uphone" value=" attacker’svalue">
<textarea name="uaddress" wrap="soft"><attacker’svalue></textarea>
<input name="update" value="update">
This form retrieves the value information from a text file. When the updateif.php is called, the information (set earlier) by the attacker is retrieved and placed in the value fields. Then the form is auto submitted and the target page is loaded. These operations are performed inside a hidden iframe, thus the victim will not see the target website.
The attacker has an admin page – – from where values values to be submitted on the target website can be set.
Example victim of CSRF attack
The admin hack panel is a control page where the attacker can set the information that will be submitted to the target website when the CSRF attack is realized.
From this website, the attacker can set new information. (Note: For the purposes of this example, there is a reset button which will reset the values of the target website) This information is stored in a file, from which the updateif.php (seen earlier) will load and submit the attacker’s value.
So, as we mentioned earlier, in order for the attacker to perform a CSRF attack and his information to be submitted, the main requirement is for the victim to be logged into the target website. When the victim visits the attackers’ website, the hidden iframe will load the code of the update profile form found in the userinfo.php (target’s update profile form) with the attacker’s desired information and auto submit them to the target website. This operation is the exact operation the victim could perform to update his profile. However, due to the CSRF vulnerability a third party entity such as an attacker can use this operation to submit malicious information without the user being able to know about it.
The attacker sets the desired information in the page and clicks ‘Update’. The information is stored in the file.
Example victim of CSRF attack
The attacker’s information is ready to be loaded when the attacker’s website is visited.
When the victim visits the attacker’s website at, nothing will happen since there is not any malicious code in the ‘Home’ page. The victim needs to access the page where the malicious code exists, and the attacker’s information will be submitted to the target website (
Example victim of CSRF attack
As soon as the victim visits the myimages.php page, the hidden iframe is loaded executing the CSRF attack. Below is the HTTP POST request which is made when the victim accesses the attacker’s malicious /myimages.php page.
Connection: keep-alive
Content-Length: 140
Cache-Control: max-age=0
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/536.5 (KHTML, like Gecko) Chrome/19.0.1084.56 Safari/536.5
Content-Type: application/x-www-form-urlencoded
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-GB,en-US;q=0.8,en;q=0.6
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
Cookie: login=acuart%2Facuart

The above HTTP POST request shows that the Host to which the POST request is sent is but the origin is with a referrer being the updateif.php page of the attackers website. Moreover, the Cookie information is included in the POST request which is the first requirement in order for the POST request to be authenticated and the CSRF to be realized. Finally, the parameters information is included in the POST request and will be submitted to the target website.
When the POST request is made the browser already has the authentication session for the target website and it includes the authentication details in the POST request as it should do in any other legitimate POST request made by the victim. This particular rogue POST request is exactly the same as a legitimate POST request with the same Host target but from a different origin. The browser, as normal, sends the POST request and the server (in this case) is not able to differentiate between a legitimate and rogue POST request since both are performed by the trusted browser in the same way.
There is not any information included in the POST request (such as a token value, seen later) which will help the server to validate a POST request as not malicious. This results in the server processing both POST requests in the normal way.
Example victim of CSRF attack
From the above image you can notice that the profile information of the victim on the target website has been changed.
The rogue information was submitted and successfully updated the victim’s profile on the target website. The victim has no indication of what happened since this operation is transparent to the user. The attacker has completed his attack successfully in this scenario. In another scenario an attacker could change the admin passwords, perform illegal transactions, and more.
NOTE: The particular operation will be performed for any user that accesses the attacker’s website. In case the particular user has an account in the target website and is logged in, then the user’s profile information will be updated with the ones of the attacker. For this particular example, we assumed that there were no security measures in place that might block the CSRF attack.

Prevention Measures

There are many suggested prevention measures that can be implemented to mitigate CSRF attacks. Some of them, though, are not complete solutions and leave room for the attack to still work. For example:
  • The use of a secret cookie – This method will not work because all cookies related to the target website will be submitted as usual as in a normal (legitimate) HTTP request.
  • Accept POST requests only – This suggestion falls short because attackers can deceive an end-user to submit a forged POST request unknowingly using social engineering methods.
  • URL Rewriting – An incomplete solution since some session information is included or exposed in the URL.
Let’s take a look at some measures that do actually mitigate a CSRF attack.

Use of Tokens

A prevention measure could be the implementation and inclusion of tokens in a user’s (current) session. Tokens are long cryptographic values that are difficult to guess. These will be generated when a user’s session begins and will be associated with this particular user’s session. This challenge token will be included in each request, which will be used by the server side to verify the legitimacy of the end-user’s request.
In order for an attacker to forge a HTTP request, they would have to know the particular challenge value (token) of the victim’s session. The disclosure of the challenge token in the URL (GET requests) should be done wisely and with awareness of the CSRF attack.
Challenge tokens can be used in the ViewState option of the ASP.NET. Since it is possible for an attacker to obtain or guess the parameter values of a ViewState then the inclusion and use of a token can make the ViewState unique and protected to CSRF attacks.
Moreover, tokens can be used in the submission of double cookies. The server-side will generate a strong random value which will be included in the submitted cookie on the user’s machine. This will act as the session ID. On sending a POST request, the website will require the particular session ID to be included as a hidden value in the submission form and be included in the cookie as well. If the two values are the same, the POST request will be considered as valid and submitted successfully. Therefore, even if the attacker is able to include any value in the form, based on the same-origin policy, the attacker will not be able to retrieve or modify the token value in the cookie and launch a CSRF attack unless they manage to guess the session ID value.

Other Security Measures

Another prevention measure is the use of challenge-response options. Despite the fact that this measure affects the user experience, it can strongly defend against CSRF attacks.
Furthermore, users should be made aware of potential threats. For example, users should:
  • Log out from web applications when they have finished using them.
  • Use the web browser with safety – that means making sure not to save any login credentials on the web browser and using legitimate and secure browser extensions.
Finally, you should scan your website using a web vulnerability scanner to detect any Cross-Site Request Forgery vulnerabilities so you can fix them before they cause any issues.
Example victim of CSRF attack
Acunetix Web Vulnerability Scanner will crawl your website, detect any CSRF vulnerabilities and alert you if any are found. It also provides you with a detailed description of weakness and the exact location your website is vulnerable, and gives you a detailed explanation on how to solve it. Make sure your website is secure bydownloading the trial version of Acunetix Web Vulnerability Scanner.


Total Pageviews