Tinder bolsters its security to ward off hacks and blackmail

This week, Tinder responded to a letter from Oregon Senator Ron Wyden calling for the company to seal up security loopholes in its app that could lead to blackmail and other privacy incursions.

In a letter to Sen. Wyden, Match Group General Counsel Jared Sine describes recent changes to the app, noting that as of June 19, “swipe data has been padded such that all actions are now the same size.” Sine added that images on the mobile app are fully encrypted as of February 6, while images on the web version of Tinder were already encrypted.

The Tinder issues were first called out in a report by a research team at Checkmarx describing the app’s “disturbing vulnerabilities” and their propensity for blackmail:

The vulnerabilities, found in both the app’s Android and iOS versions, allow an attacker using the same network as the user to monitor the user’s every move on the app. It is also possible for an attacker to take control over the profile pictures the user sees, swapping them for inappropriate content, rogue advertising or other type of malicious content (as demonstrated in the research).

While no credential theft and no immediate financial impact are involved in this process, an attacker targeting a vulnerable user can blackmail the victim, threatening to expose highly private information from the user’s Tinder profile and actions in the app.

In February, Wyden called for Tinder to address the vulnerability by encrypting all data that moves between its servers and the app and by padding data to obscure it from hackers. In a statement to TechCrunch at the time, Tinder indicated that it heard Sen. Wyden’s concerns and had recently implemented encryption for profile photos in the interest of moving toward deepening its privacy practices.

“Like every technology company, we are constantly working to improve our defenses in the battle against malicious hackers and cyber criminals,” Sine said in the letter. “… Our goal is to have protocols and systems that not only meet, but exceed industry best practices.”

Social – TechCrunch

Improvements to security settings on public computers in the National Art Library

Here at the National Art Library, we appreciate hearing from visitors about our services. Your feedback, combined with our need to ensure we comply with Cyber Essentials and the Data Protection Act 2018, has led to an update in the settings on our public computers. The computers remain accessible to everyone and free of charge in our reading rooms.

We are happy to announce the following changes –

  • All data will be wiped after each session, activated by closing the internet browser after use.
  • You will still be able to use the PCs to access the library catalogue, to consult subscription content, to browse the internet and can save files to USB sticks as needed (USB sticks are available for purchase in the library for £5), but this will be done slightly differently.

To enable these new settings, you will see that the computers look and behave differently to what you may be used to. If you are in the Library and need any assistance, Library staff will be on hand to help you.  Otherwise, please contact us online with any enquiries.

Please be aware that we do not hold a public licence for Microsoft Office software and this is not offered as an application on the computers.  However, you can use online versions such as Word online or Google docs for word processing.

Help sheets are available to help you use our new computer settings –

  • Keyboard shortcuts for accessibility
  • Web-based Office applications
  • Downloading, emailing and saving PDFs to personal devices.


Five Steps to WordPress Security (with a Sixth Thrown in for Good Luck)

Editor’s note: This post was written by Andrew May, the owner of a well-established web design agency Mays Digital in London,England. He has many years experience in website design and development and has a passion for writing articles and tutorials related to this industry.

Being an incredibly popular content management system, WordPress is one of the main platforms designers and devs have to work on. It is way ahead of other CMS such as Joomla and Drupal. W3Techs who look at the type of technologies used across the web, have found that more than 60% of the websites where the CMS is known, use WordPress as the underlying technology.

WordPress is also one of the most targeted technologies by hackers, often because of poorly written plug-ins, which allow hackers to exploit software vulnerabilities. For example, the RevSlider plug-in attack of 2014 that used the plug-in as the vector in the SoakSoak hacker attack, resulted in well over 100,000 websites being compromised.

Hackers are really going for it at the minute and the number of general cyber threats are increasing massively, so we need to be aware of what steps we can take to make sure our WordPress website is protected against hackers.

The following areas show where you should concentrate your efforts in protecting your site. These are the places that are most vulnerable and used to exploit WordPress, to either compromise data, or carry out a denial of service attack (DOS).

Here are five steps to WordPress security (and then some).

Area 1: Your admin and other user sign in security

This is a fundamental check box to get right in terms of security. The WordPress login point is well known as an attack vector and brute force attacks are often used against this point of entry. A brute force attack is a remote, automated attack whereby (usually) the wp-login.php file is targeted and many multiple tries at entering username and password is made until, hey bingo, entry is gained.

steps to wordpress security

There are a number of ways you can prevent this happening:

  1. Don’t use obvious usernames, such as ‘admin’
  2. Use a strong password that has special characters and is a reasonable length (this add ‘entropy’ to the password making it harder to guess). However, hackers are really on the ball when it comes to passwords and people tend to use common patterns when creating, even seemingly strong passwords. Security specialists, KoreLogic have an interesting article on this issue.
  3. Use 2nd-factor authentication. That is a credential, entered after you’ve also entered your username and password. 2nd-factor authentication is great for preventing brute force and other types of authentication based attacks. There is a number of plug-ins that let you use various forms of 2nd-factor authentication.  For example the DUO plug-in lets you set up a number of mobile-based authentication methods, such as SMS text codes and passcodes for a DUO mobile app
  4. If you don’t like to use 2nd-factor authentication (and I admit, it can be a pain), then you could use a plug-in that applies Captcha. An example of a Captcha that is fairly simple to use, is a mathematic based Captcha plug-in such as Math Captcha. Captcha also helps to prevent brute force attacks, but it doesn’t prevent more individually targeted attacks.

Area 2: Keeping your plug-ins and WordPress patched

Hackers use vulnerabilities in software to help carry out intrusions on WordPress sites. Plug-ins have the same sorts of vulnerabilities and being aware of issues and making sure that you promptly patch your plug-ins is a crucial part of your WordPress security housekeeping.

WordPress is very susceptible to cross-site scripting (XSS) attacks and many WordPress plug-ins have allowed WordPress to become susceptible to this type of attack. A recent analysis (April 2015) by security researchers, Sucuri, found many of the most popular WordPress plug-ins have are XSS vulnerable. The list of those affected can be found here.

XSS attacks can also be applied using WordPress comments. As well as being able to exploit vulnerabilities in Plug-ins, WordPress sites have the potential for an XSS attack if a hacker puts executable JavaScript in a comment. This JavaScript then gets executed when it gets sent back to the browser – i.e. when the comment subsequently gets displayed, the XSS attack is executed.

There are two ways this can be prevented. The first and least effective way is to protect against this by preventing the JavaScript being sent to the browser by filtering. However, this can fail if a hacker encodes the JavaScript first. In addition, some of these filters can be very badly written and just don’t work. The second and more effective way to prevent XSS attacks is to encode the output to the browser so it goes out in a form that can’t be executed in the browser. The only issue here is that even these can be problematic if you allow HTML comments to be posted. An excellent post by the WordPress team on ‘output escaping’ can be read here.

WordPress itself has recently been found to be vulnerable to XSS attacks as a zero day vulnerability in WordPress 4.2, 4.1.2, 4.1.1. and 3.9.3. Again this attack centered around using comment fields to inject JavaScript. WordPress have recently released a patch to fix this in version 4.2.1 so make sure you’ve got that version.

As well as plug-ins and WordPress patching, also make sure you’re running the latest versions of PHP and any database software too, such as MySQL; if in doubt, patch.

Area 3: Themes and keeping them secure

Themes are another area where attacks can come in. You should always be careful where you get your WordPress theme. Free themes are abundant, but they are also a great way for Hackers to get malicious code into your site, so beware of the origins of a theme, best off sticking to the WordPress recommended themes or creating one yourself.

One other way that hackers can gain control of your site is to by using the plug-in and theme editor to upload either malicious code or their own malware-ridden theme. WordPress has some good advice on how to disable this feature and so prevent this being used as an attack vector.

You can also get plug-ins, which check themes for security robustness, an example being, Theme Check.

When coding you really must practice secure coding techniques and SpyreStudios have an excellent article on secure coding techniques for PHP that help minimize security vulnerabilities from the outset.

Area 4: Preventing Denial of Service Attacks

Denial of service attacks (DOS) result in a website being crashed by a hacker. In 2014, Sucuri, found that 162,000 legitimate WordPress sites had been used in a botnet based, distributed DOS attack (DDOS). The attack utilized the Pingback function in WordPress via an API interface XML-RPC. However, it has proven tricky to disable this feature without severely affecting many other plug-ins such as Jetpack.

You can disable ping-back requests specifically by adding a line shown below to your functions.php file after add_filter:

unset( $ methods[‘’] );

Alternatively, you can use a Web Application Firewall or WAF which can prevent this type of attack as well as others and I’d recommend using one as a fundamental of WordPress security. You can also get plug-ins which specifically disable the pingback in XML-RPC, an example being XML-RPC Pingback.

As an aside, you can find out if your website was part of the DDOS attack using this DDOS scanner.

Area 5: Specific Security Plug-ins and Coding

As we’ve discussed, there are many attack vectors within the WordPress platform that can be exploited by hackers. One of the ways you can help mitigate this is to use a security plug-in. As mentioned previously a WAF is a good starting point for security and an example is Ninja Firewall.

And Finally: Audit, back up and back up again

Getting security right is something that even the experts can’t manage. It’s being realistic, not fatalistic to assume that you may be, at some point, hacked, so backup your data and files regularly. In addition, you should also have some good audit in place, so if things do go badly, then at least you can work out what went wrong so it doesn’t happen again.

There are many good security audit plug-ins that will monitor and alert you of any security issues, an example is WP Security Audit Log.

There are also many backup plug-ins that can be used for WordPress website backups. You’ll need to research which one is right for you. But whichever, do the backups regularly and if you do get hacked, at least you have all of your files and data to rebuild.

Here’s more on WordPress:

Essential WordPress Plugins to Make the Designer’s Life Easier

The post Five Steps to WordPress Security (with a Sixth Thrown in for Good Luck) appeared first on SpyreStudios.


Introduction to WordPress Front End Security: Escaping the Things

If you’re a WordPress developer that writes HTML/CSS/JS (which is 100% of theme developers and 99% of plugin developers), you need to know the basics of front end security for WordPress. WordPress gives you all the tools you need to make your theme or plugin secure. You just need to know how and when to use each tool.

For example, one huge responsibility you have as a front-end developer is to prevent unescaped content from being printed to the page.

Security Is Your Responsibility

Before we talk specifics, I’d like to squash an idea that I would (previously) use to rationalize a “less strict” view of front end security:

“If a hacker is already able to change the code/database/content, what difference does it make if my front-end code is secure? Couldn’t they already do more substantial damage?”

Yes, if a hacker already has control of the code or database, chances are they don’t care how well-secured the output is (they can probably change it anyway).

Even so, you still have a responsibility to make the front-end code secure. A few reasons why:

  • Proper front end security also prevents user error from causing big problems. If the user accidentally puts a special character in a field they weren’t supposed to, the page won’t explode.
  • Some attacks are limited. Perhaps the hacker had minimal control and could only change a single piece of content in the database. You can prevent that narrow attack from becoming much larger.
  • Security is an onion. The outermost (often inedible) layer is the front-end display. Good security practices make it that tiny bit harder for a hacker to exploit a site.

Enough with the pep talk. Let’s talk about securing our WordPress themes and plugins.

What Are We Worried About?

A major concern for a front end developer is avoiding Cross-Site Scripting (XSS for short, because ‘CSS’ would cause all sorts of problems. Puns and one-liners welcome.).

XSS vulnerabilities allow bad people (“hackers”) to steal information. Typically that means stealing cookies and session information. If a bad person can send your active session back to themselves (hence the “cross site” part), they could use that to be logged in to your account and do anything you could do (bad news bears).

What is Escaping?

In computer science the word “escape” has a special meaning:

To convert a character or string of characters to be interpreted literally within a specific context, typically to prevent those characters from being interpreted as code.

Put another way, in the context of WordPress front-end development: Escaping changes possibly evil content into safe content.

The biggest danger here is generally <script> tags and other methods of executing JavaScript (e.g. onclick="javascript:"). If a <script> can be output on the page an executed, that’s super dangerous. Escaping means turning that into &lt;script&gt; which is safe.

Why You Need To Escape: An Example

In case you’re not familiar with XSS, a quick example will demonstrate the risk.

Suppose your theme had a field to add a link for further reading. A “Read More” link, if you will. On the WordPress dashboard, it might look like this:

Custom Field

In your theme, you’d like to display this link at the bottom of the post, like so:

Custom Field on the Front End

So, you open up single.php (the file responsible for displaying blog posts) and add the following near the bottom:

<?php    $  read_more_link = get_post_meta(      get_the_ID(),      'read_more_link',      true    );  ?>  <!-- Don't do this --> <a href="<?php echo $  read_more_link; ?>">Read More</a>

Suppose someone maliciously enters this text into your custom field:

Custom Field With Evil Script

When you visit the page, here’s what you’ll see:

Evil Script Executed!

Yikes! If that bad input allowed a bad person to execute JavaScript, they could:

  • Redirect the user
  • Hijack the user’s cookies
  • Do other bad things

An Escape for Everything

Now that we know how important escaping is, let’s look at the escaping methods WordPress provides and give some context for each.

Function: esc_html

Used for: Output that should have absolutely no HTML in the output.

What it does: Converts HTML special characters (such as <, >, &) into their “escaped” entity (&lt;, &gt;, &amp;).

A common example would be displaying text-only custom fields in a theme:

<?php $  dog_name = get_post_meta( $  post_id, 'dog_name', true ); ?> <span class="dog-name"><?php echo esc_html( $  dog_name ); ?></span>

Codex entry for esc_html

Function: esc_attr

Used for: Output being used in the context of an HTML attribute (think “title”, “data-” fields, “alt” text).

What it does: The exact same thing as esc_html. The only difference is that different WordPress filters are applied to each function.

Here’s esc_attr used on an image:

<img src="/images/duck.png"  alt="<?php echo esc_attr( $  alt_text ); ?>"  title="<?php echo esc_attr( $  title ); ?>" >

Codex entry for esc_attr

Function: esc_url

Used for: Output that is necessarily a URL. Examples would be image src attributes and href values.

What it does: A more thorough, specific escaping than the esc_attr & esc_html functions, which removes or converts any characters not allowed in URLs into their URL-safe format.

Use esc_url when you need to output a link or dynamic image path:

<a href="<?php echo esc_url( $  url ); ?>">Link Text</a> <img src="<?php echo esc_url( $  image_url ); ?>" >

Codex entry for esc_url

Function: esc_js

Used for: Printing JavaScript strings, primarily on inline attributes like onclick.

What it does: Converts special characters like <, >, quotes – anything that could break JavaScript code.

esc_js is probably the least used of the esc_ functions, for a few reasons:

  1. Most JS is loaded in a separate file.
  2. Most JS isn’t written inline as attributes.
  3. For non-inline JS, json_encode is a better option.

But, if you ever need to escape some inline JS, here’s how you’d do it:

<?php $  message = get_post_meta( get_the_ID(), 'onclick_message', true ); ?> <a href="/blog/" onclick="alert('<?php echo esc_js( $  message ); ?>')">...</a>

Codex entry for esc_js

Function: json_encode

Used for: Printing a PHP variable for use in JavaScript.

What it does: Converts a PHP variable (object, string, array, whatever) into a sensible, escaped JavaScript representation of that PHP variable.

Useful in particular for <script> blocks making use of WP variables. A simple example:

<?php $  categories = get_categories(); ?> <script type="text/javascript"> 	var allCategories = <?php echo json_encode( $  categories ); ?>; 	// Do something interesting with categories here </script>

PHP reference for json_encode

Function: wp_kses

Used for: Output that needs to allow some HTML, but not all tags or attributes.

What it does: Strips the content of any tags or attributes that don’t match the list of rules passed in.

Use wp_kses if there is a context that allows certain tags (e.g. inline formatting tags like <strong> and <em>) to be printed as HTML.

A basic example would be displaying comments:

<div class="comment-text">   <?php              echo wp_kses(        $  comment_text,        // Only allow <a>, <strong>, and <em> tags       array(         'a' => array(           // Here, we whitelist 'href' and 'title' attributes - nothing else allowed!           'href' => array(),           'title' => array()         ),         'br' => array(),         'em' => array(),         'strong' => array()        )     );   ?> </div>

Codex entry for wp_kses

What are the _e and _x versions of the escaping functions (esc_attr_e, esc_attr_x)?

These are convenience functions (to make your life easier), and they’re useful when printing translatable strings: text that can be changed with a WordPress translation file.

If you’re developing a theme or plugin for wide distribution (vs. a one-use client project), you’ll want to make every string internationalization-friendly. That means PHP strings that were once under your control become editable by translators – hence the need for escaping (you can’t trust anybody):

<a href="/blog/" title="<?php esc_attr_e( 'Go To Blog', 'my_theme' ); ?>">Blog</a>

The second parameter to the _e functions is the translation domain. It is used by translators when they write and generate their translations.

The _x functions (like esc_html_x) are essentially the same as their _e counterparts, with an added “context” argument to explain the context a word or phrase is used in. Useful for words with multiple meanings:

<!-- Here, we're asking the user to comment (verb): --> <a href="#comment">   <?php      echo esc_html_x(        'Comment',        'Verb: To leave a comment', // Here's the contextual help       'my_theme'      );    ?> </a> <!-- Here, we're simply adding a heading with the text "Comment" (noun) --> <h3>   <?php      echo esc_html_x(        'Comment',        'Noun: An individual comment', // Here's the contextual help       'my_theme'      );    ?> </h3>

Codex entry for esc_attr_e
Codex entry for esc_attr_x

What about the_title and the_content?

If you crack open the default WordPress theme (named “Twenty Fifteen” at the time of this writing), you’ll see code like this outputting the title of a post:

<header class="entry-header">     <?php the_title( '<h1 class="entry-title">', '</h1>' ); ?> </header><!-- .entry-header -->

You’ll also see unescaped calls to the_content like so:

<?php the_content(); ?>

You may be panicking. Why aren’t those functions escaped?! 2 reasons:

1. WordPress automatically escapes them

Functions like the_title are convenience functions – tools that make front-end development easier. As such, to make it even easier for developers, WordPress already automatically escapes the output for the_title.

2. Context: Some Content is HTML

In the case of the_content, the output is expected to be unescaped HTML. When the user adds a <div> to their content, we can assume they actually want a <div> output to the page – instead of the escaped version.

If you have security concerns with a user being able to add scripts to the_content‘s output, you can use wp_kses to strip unwanted tags from the final output. This would be useful on subdomains and shared hosting, and I’m pretty sure this is what they use on (a hosted version of WordPress where users aren’t allowed to add their own JavaScript).

Handy tip: If you want to use the_title as an HTML attribute, use the_title_attibute to save yourself an escape. the_title_attribute in action:

<span title="<?php the_title_attribute(); ?>">...</span>

Escape the Things

I work with a lot of plugins and themes – commercial, free, and custom-built – and I see lots of unescaped content (and resulting XSS vulnerabilities). Hopefully, this article will equip you with the basic tools you need to make your WordPress things safer.

Did I overlook anything? Let me know in the comments!

Introduction to WordPress Front End Security: Escaping the Things is a post from CSS-Tricks


WordPress Front End Security: CSRF and Nonces

In our last article, we covered Cross-Site Scripting (XSS) and the functions WordPress provides to prevent XSS attacks. Today, we’ll look at another security concern for front end developers: Cross-Site Request Forgery (CSRF).

Lest you think this security stuff isn’t important, a major vulnerability was recently found in the WP SEO plugin, which is installed on 1,000,000+ WordPress sites and which allowed hackers to manipulate the WordPress database using CSRF. (The plugin was fixed quickly, but you can see how scary this stuff can be.)

Nonces and Cross-Site Request Forgery

Put simply, CSRF is when bad guys try to trick users (usually someone with access to the WordPress dashboard) into doing something they didn’t intend to do. A simple example can help illustrate:

Suppose you were building a WordPress plugin to allow logged-in users to submit their pictures. On the front end of the site, your plugin might generate a form like so:

<?php if ( is_user_logged_in() ) : ?>   <form action="/submit-picture/" method="get">     <input type="text" name="picture_url">     <input type="submit">   </form> <?php endif; ?>

On the back end, you handle the picture form submissions:

if ( is_user_logged_in() && isset( $  _REQUEST['picture_url'] ) ) {   // Save the picture here }

Now, suppose a hacker wants to submit a fake picture. The hacker doesn’t have a username or password – so they can’t do anything, right?

Not quite. To hijack one of your users’ accounts to submit a fake picture, the hacker could try to get a logged-in user to click a link that looks like this:

If a logged-in user clicks that link, what would stop the picture from being submitted? You guessed it: Nothing. Hacker wins.

That’s because we didn’t do anything to verify the user’s intention to submit a picture. The “F” in CSRF stands for forgery: The hacker has forged (faked) a request on behalf of the user, kind of like how you forged your mom’s signature on sick notes in elementary school.

How to Prevent CSRF

We can stop CSRF attacks by using some handy functionality built into WordPress. To prevent a request from being successfully “forged”, WordPress uses nonces (numbers used once) to validate the request was actually made by the current user.

The basic process looks like this:

  1. A nonce is generated.
  2. That nonce is submitted with the form.
  3. On the back end, the nonce is checked for validity. If valid, the action continues. If invalid, everything halts – the request was probably forged!

Let’s Add a Nonce

On the front end, suppose we wanted to add a nonce to a form submission. We’ll do this with the wp_nonce_field convenience function:

<form action="/submit-picture/" method="get">   <input type="text" name="picture_url">   <input type="submit">   <?php wp_nonce_field( 'submit_picture' ); ?> </form>

Easy, right? Now, when we’re processing this form on the back end, we just need to use some built-in WordPress functions to verify that the nonce was valid:

// By default, we can find the nonce in the "_wpnonce" request parameter. $  nonce = $  _REQUEST['_wpnonce']; if ( ! wp_verify_nonce( $  nonce, 'submit_picture' ) ) {   exit; // Get out of here, the nonce is rotten! }  // Now we can process the submission if ( is_user_logged_in() && isset( $  _REQUEST['picture_url'] ) ) {   // Save the picture here }

Because the nonce is unknown to the hacker, he can’t craft a fake link that will do harm. Any malicious attempts will be squashed at the wp_verify_nonce check. We’ve stopped the hacker, right?! For many cases, yes. We’ve made it much more difficult for a hacker to forge a request.

Nonces are User-Specific

But what if a bad logged-in user of your site wanted to submit a fake picture for another user? Couldn’t the bad user could just look at the HTML source of the site, find the nonce field, and add it to their “evil” URL like so?

Fortunately, it won’t work. WordPress nonces are unique to a user’s session, so a hacker couldn’t substitute his own nonce for another user.

Hat tip to Mark Allen in the comments for pointing out session-unique nonces.

Try These Nonce Functions

WordPress is full of convenience functions to make generating nonces (and preventing CSRF) easier. Here are a few you might find useful for different situations:

Function: wp_verify_nonce

What it does: Validates that the nonce value was legitimately generated by WordPress.

No matter how you generate your nonce, it should be checked on the back end with wp_verify_nonce

Just like the examples above, use wp_verify_nonce to verify a user’s intent:

$  submitted_value = $  _REQUEST['_wpnonce'];  if ( wp_verify_nonce( $  submitted_value, 'your_action_name' ) ) {   // nonce was valid... }

Codex entry for wp_verify_nonce

Function: wp_nonce_field

What it does: Prints a hidden <input> tag containing a nonce value.

Used when you’re building a <form> that needs to be protected from CSRF (which is pretty much every <form>).

Just like in the examples above, wp_nonce_field is a convenience function to make our life easier building HTML forms:

<form> <!-- Other form fields go here --> <?php wp_nonce_field( 'your_action_name' ); ?> </form>

Codex entry for wp_nonce_field

Function: wp_nonce_url

What it does: Returns a URL with a nonce value attached.

Used when you’re building a URL that needs a nonce field appended as a query string parameter. Most useful when doing GET requests that need CSRF validation.

Here’s an example of wp_nonce_url where we need to validate that a user intended to click a link:

<?php   $  action_url = wp_nonce_url( '/change-color/?color=blue', 'change_color' );   // $  action_url is now "/change-color/?color=blue&_wpnonce=GENERATED_VALUE" ?> <a href="<?php echo esc_url( $  action_url ); ?>">Change to blue</a>

Codex entry for wp_nonce_url

Function: wp_create_nonce

What it does: Generates a nonce value.

Used when you need a nonce value that doesn’t fit one of the above convenience functions.

Here’s wp_create_nonce used to generate a nonce value for returning in JSON format (useful for returning in AJAX requests):

<?php   $  nonce_value = wp_create_nonce( 'your_action_name' );    return json_encode( array( 'nonce' => $  nonce_value ) ); ?>

Codex entry for wp_create_nonce

Function: check_ajax_referer

What it does: Checks for a submitted nonce using wp_verify_nonce, and if the validation fails, stops execution.

check_ajax_referer is another convenience function mainly for use in AJAX requests. You can use it to skip doing the wp_verify_nonce check yourself:

<?php   // Forged requests won't get past this line:   check_ajax_referer( 'your_action_name' );    // Do your action here ?>

Codex entry for check_ajax_referer

Nonces for Everything!

CSRF vulnerabilities range from harmless (e.g. poll submissions) to extremely dangerous (e.g. modifying passwords or permissions).

Regardless of severity, you should be using nonces to prevent CSRF any time a user does an action in WordPress. Because…why wouldn’t you? You don’t want hackers forging requests on your site, and WordPress gives you the tools to stop them.

Use nonces, stop forgery, and foil hackers!

WordPress Front End Security: CSRF and Nonces is a post from CSS-Tricks