dennisgorelik | Entries tagged with security

Couple of years ago security pen testers found clickjacking bug in Google API Explorer:
===
https://threatpost.com/google-patches-clickjacking-bug/112568/
Google did pay out a $1,337 bounty
“The idea behind the exploit is to frame the page where that button was, and make the frame transparent.”
===

Demo
Here is the demo of how highjacking setup page looks like:

<html>
Hijacker's web site content that invites user to click somewhere:
<p><input type="button" value="Click to see cats' videos"></p>
<style>
iframe { 
width:600px;
height:600px;
position: absolute;
top: 0; left: 0; 
filter: alpha(opacity=50); 
opacity: 0.50;
}  
</style>
<iframe src="https://www.wikipedia.org">
</html>

Note that Wikipedia's security team made a conscious choice to allow clickjacking of their home page, because there is nothing at risk there.
But if you click "Log in" (or replace "https://www.wikipedia.org" with "https://en.wikipedia.org/w/index.php?title=Special:UserLogin&returnto=Test" in the demo html above) - you would notice that Wikipedia login page is not rendered in the iframe.

How did Wikipedia do that?
I opened Fiddler2 debuggin proxy and found out that "https://en.wikipedia.org/w/index.php?title=Special:UserLogin&returnto=Test" renders this HTTP header:

X-Frame-Options: DENY

But "https://www.wikipedia.org" page does NOT render that header.

How to prevent clickjacking?
Extra experimenting showed that google.com, twitter.com and indeed.com use "X-Frame-Options: SAMEORIGIN"
facebook.com uses "X-Frame-Options: DENY" (the same as Wikipedia login page).
--------
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options
There are three possible directives for X-Frame-Options:
X-Frame-Options: DENY
X-Frame-Options: SAMEORIGIN
X-Frame-Options: ALLOW-FROM https://example.com/
--------

What is the best practice for using "X-Frame-Options"?
I am trying to decide what "X-Frame-Options:" should I use for postjobfree.com
Does the flexibility of iframe worth the security risk?
Should we support web site that include postjobfree.com content into their own iframe?
Such iframe support has both cons and pros...

Why secure option is not a default choice in browsers?
What do you think, why browsers (such as Google Chrome and Firefox) do not assume "X-Frame-Options: SAMEORIGIN" by default?
If allowing loading your page content into parent iframe is inherently insecure, then such a risky behavior should be explicitly requested, right?

Crossposts: http://dennisgorelik.livejournal.com/138595.html

Couple of days ago a scam team, in order to sign up for premium membership on postjobfree.com -- hacked couple of real business emails: jdicken@c21patt.com and heidi@heidiburns.com
Both emails seems to belong to real estate agents.

I was able to find and reach actual owners of these email addresses on the phone.
They do not seem to be very concerned about their email addresses being compromised.
Both email owners confirmed that they did not make premium orders on our web site and then indicated that they prefer to continue with their other business instead of digging deeper into that email hacking ...

How much would you care if you learned that your email account was hacked?

Crossposts: http://dennisgorelik.livejournal.com/135671.html

When developing a user-facing application, prioritization of security versus usability - requires delicate balancing.

Here are some examples:

1) When postjobfree emails to a user account recovery link, we want to make that the link is usable, and allow user to use that link for a day (24 hours).
In some scenarios such account recovery link could be usable for the user even after 24 hours. But such a long window for taking over an account based on a single link would be making postjobfree.com account less secure (what if an attacker get an access to an old "account recovery" link?).

2) When user opens that account recovery link, PostJobFree allows user to set a new password, and it also autologins user to that account.
But what if user opens the same link for the second time: should PostJobFree allow user to change account password and autologin again or not?
From security perspective it is safer to expire such a link immediately after user opened the link.
From usability perspective it is better to allow that link to work for the second time, because user may accidentally open that "account recovery" link twice. Or an antivirus program may pre-open email link before user opens it.
In order to balance these security and usability demands, we decided to allow account recovery link to work for 1 hour after it was already used (unused account recovery link can be used for up to 24 hours).

3) What if user changed password on his account: should we allow old account recovery links to work or not?

Here is a typical "security" scenario:
User account owner found that an attacker (or a former employee) has an access to the account. So the account owner changes the password and expects that the attacker would not have an access to the account anymore. But if the attacker still has an old account recovery link - he can still autologin.
So, from security perspective, we should immediately expire all "account recovery" links that were sent before password change.
However there is an important "usability" scenario too:
- User posts a job, which creates a new account for the user.
- PostJobFree emails "confirm email" link to the user:
===============
From: PostJobFree <noreply@postjobfree.com>
To: testuser@gmail.com
Subject: Confirm your PostJobFree registration

===============

("Confirm email" link functions similar to "account recovery" link).
- While waiting for that "confirm email" link to arrive in the email inbox, user sets up a password on that new account (as a part of a new account setup process).
- Then user opens "confirm email" link.
If, according to security demands, "password change" in the previous step expired such "confirm email" link, then an important piece of usability is lost: user cannot immediately confirm that email is functioning, and has to request another "confirm email" link.
So, how do we balance these contradictory demands between security and usability in this case?
The best approach seems to be to prioritize usability in cases when user sets up a new account, but prioritize security when user changes password on already established account.
So if user changed password while going through initial account setup wizard - then keep previously sent links functioning. But if user already had password set, and now decided to change the password again - then expire all past "account recovery", "confirm email" and "change email" links immediately.
Such granular balancing between security and usability allows to deliver good security to the users who care about security of their account (users who change their account passwords manually -- such users are a minority), but still deliver a good usability to the vast majority of users who setup their password only if they are nudged by the account setup wizard.

Crossposts: http://dennisgorelik.livejournal.com/134276.html

Starting from 2016-01-20 our old unit tests for PayPal integration functionality do not work anymore.
PayPal changed how their sandbox API works.

----------
https://www.paypal-knowledge.com/infocenter/index?page=content&id=FAQ1766
On January 19-20, 2016
The Sandbox endpoints will be upgraded to new SHA-256, 2048-bit certificates:
...
After June 17, 2016
The Production endpoints will be upgraded to new SHA-256, 2048-bit certificates:
----------

Here's the upgrade instructions from PayPal
===========
https://devblog.paypal.com/paypal-ssl-certificate-changes/
How to Update to Prevent Service Outage
To prepare for these changes, please use the checklist below to ensure everything has been upgraded completely:

Talk to the technical contact or 3rd party partner that you used to create the checkout.
Save the VeriSign G5 Root Trust Anchor in your keystore.
Upgrade your environment to support the SHA-256 signing algorithm.
Perform end-to-end testing of the integration against the Sandbox / Payflow Pilot environment (including Instant Payment Notifications (IPN), Payment Data Transfer (PDT), and Silent Posts).
===========

Why do I need to save certificates into my keystore in order to maintain PayPal integration?
Why cannot they use our standard SSL certificate that we already have installed on our web server?

Why PayPal gives no instructions about how to "Upgrade our environment to support the SHA-256"?

It looks like PayPal architects simply do not care about what their customers (developers) will have to go through in order to maintain their API.

Ironically, revenue from PayPal is less than 10% of our revenue, so maintaining all that complexity associated with PayPal API integration does not make sense.

Update:
Facebook discussion

At PostJobFree we are sending out multiple emails.
For example, job search alerts.

These emails have links, and these links allow us to track users.

In addition to tracking user we may autologin users to our web site to make their life easier.
At the same time autologin from email link could be a security concern: what if a job seeker forwarded that email to a recruiter, so now that recruiter can autologin as the job seeker.

It's pretty much a trade off between convenience and security.

So far we allow job seekers to autologin using links in job alerts we send to them.
But we do not autologin recruiters:
Recruiters on average are more computer savvy and are able to autologing.
Recruiter's account is move valuable than average job seekers' account.

We also do not autologin based on old links (only 7-days old links support autologin).

What do you think: should we autologin users based on email links?

Dennis Gorelik

Entries tagged with security

Clickjacking security vulnerability

People do not care much about their business email being hacked

Security vs Usability tradeoff

PayPal breaks their API

To autologin or not to autologin?

Profile

June 2025

Syndicate

Most Popular Tags

Page Summary

Style Credit

Expand Cut Tags