Why you should apply to Stony Brook if you want to pursue a PhD in computer security and privacy

I remember it as if it was yesterday. I was entering the second year of my MS degree in Computer Science, when I realized that I wanted to pursue a PhD in Security outside of Greece. Where should I apply? Where does one go in order to work on security? Should I go to one of the very well known universities that everyone knows from Hollywood movies? Will they accept me? Or maybe I should go to a place where I actually know someone’s research and I really really want to work with them? What kind of research do I like?

It has been eight years since I asked these questions and I now find myself on the other side of things. How do I find smart, capable, hard-working young students and get them to apply for a PhD at Stony Brook? Therefore, the purpose of this blog post is to lay in front of you all the reasons why you should apply to Stony Brook if you are interested in Security and Privacy.

Continue reading

Posted in Miscellanea | 2 Comments

Poor reasons to reject a computer security paper, Part 2

I was surprised with the popularity of Part 1 of my series “Poor reasons to reject a computer security paper”. I am interpreting this as a sign that I may be on to something. If you haven’t read Part 1, please do so, not just for the sake of completeness but so you can also understand my motivation for writing these posts (I am, categorically, not trying to claim any kind of moral superiority because I have made similar comments in the past).

The second poor reason to reject a paper:

“This paper is below the bar of X”

TLDR: Do not reject a paper based on your subjective judgement of a conference’s prestige.

This is a close second to the “a blog post has shown this” comment. Variations of this comment include “this paper does not reach the bar of X”, “this paper is not deep enough for X”, “this is a fun paper but clearly unsuitable for X”. Occasionally, the reviewer will suggest a more “appropriate” alternative which is, always, a less prestigious venue than the one that the paper is currently submitted to:

  • “The authors should send this to workshop so-and-so”
  • “I am sure that a lot of people would find this work interesting if presented as a poster”
  • “The back of a Dunkin Donuts napkin is an appropriate dissemination method for this work”

My claim is that this comment is often wrong, and when it is not wrong, it is unnecessary.

As far as I can tell conferences do not have set “bars.” Reviewers give a score to each paper and then the chairs (as well as the reviewers in the PC meetings) take these scores and use them to accept the top N papers, where N is the number of papers that a conference can (or is willing to) accommodate. Sure, you can have champions that pull a paper despite opposition and strong opposers who want to make sure a paper is not accepted despite favorable reviews, but other than that, it is the set of all reviews that eventually determine who is in and who is out.


Another problem with bar-setting is that it is a subjective, often unreliable, metric. People are much more likely to be judgmental towards a paper that they understand well (e.g. it is in their own field of research or is just an easily approachable paper) than one that they do not. Moreover, it appears to me that this subjective bar is actually a quale. One cannot really explain what makes this bar or how it is set… they can only tell you what is above it and what is below it. I have gut feelings too, but it’s exactly those that we are supposed to be actively working against in science.

Finally, even if indeed a paper is clearly unsuitable for a top conference (e.g. because of underdeveloped ideas, unwarranted assumptions, key experiments missing, or identical related work), one can rest assured that given enough constructive criticism, the authors will eventually figure it out by themselves without having to be explicitly told.

Posted in Poor Reasons | Leave a comment

Poor reasons to reject a computer security paper, Part 1

In 2016, at the time when I am writing this (July), I have been a PC member for seven different security conferences including two of the top ones, CCS and USENIX Security, and I have reviewed upwards of 80 papers. This year has also been the year where a certain paper of mine that I really believe in, gets rejected over and over again for all the wrong reasons. Being a reviewer, I have seen fellow reviewers making the same comments that my paper has been receiving to other peoples’ papers.

I saw enough of those to be inspired to write a series of blog posts. Do note that I am a junior faculty and I do not have tens of years of experience from which I can distill deeper truths. I do, however, think that these observations are true and we must, both individually as well as corporately, correct the errors of our ways. I am saying “our ways” because I am guilty of the same offenses. Continue reading

Posted in Poor Reasons | 1 Comment

ShapeShifter: The emperor’s new web security technology

Disclaimer: Everything that I say in this blog post about ShapeSecurity and their ShapeShifter product, is based on their YouTube video, their description of their product on their pages, and an article on PandoDaily. As such, the product may be much more sophisticated than I think it is (if so, they should have really given better examples) in which case, what you read below may not be 100% correct.

The emperor's new clothes

The emperor’s new clothes

On one of my daily Twitter rounds, I noticed someone talking about this great product that will revolutionize web security. What does this product do you ask? It uses “polymorphism” to constantly change a page’s HTML code so that bots won’t be able to appropriately interact with the page. This means, according to the company, that all bad things that bots do (automatic signups, spam, credential testings, etc.) will seize. At the same time, the page remains identical for human users who will have no problems interacting with the page. Here’s the presentation of their product:

Continue reading

Posted in Breaking stuff | 6 Comments

Detecting Ghostery


I discovered Ghostery in the summer of 2012, when I was researching web-tracking and specifically web-tracking done through web fingerprinting. Ghostery is a really cool browser extension which helped me identify the domains that popular web fingerprinters used to deliver their code and thus allowed me to isolate and study the fingerprinting code. You can read all about that in our paper titled: “Cookieless Monster: Exploring the Ecosystem of Web-based Device fingerprinting“.

Since then, I’ve installed Ghostery in all my browsers and use it to quickly find out which third-party trackers, each website uses. For those of you who don’t use Ghostery (you should definitely check it out after you finishing this post), Ghostery will match network requests and JavaScript/HTML filepaths with third-party-tracker blacklists and notify you when it gets a match. It also has the ability to block specific trackers, from running altogether.

Continue reading

Posted in Breaking stuff | 19 Comments

You are what you include: Large-scale evaluation of Remote JavaScript inclusions

Today, I am back to Belgium, after spending one week in the US. I was in Raleigh, NC, to attend the 19th ACM conference on Computer and Communication Security and to present our paper titled You Are What You Include: Large-scale Evaluation of Remote JavaScript Inclusions. KU Leuven had an all time record this year, since we had 4 (!) full papers accepted.

In this post, I want to summarize the findings of our remote inclusions study so that you can get a glimpse of the size of the problem and hopefully get curious enough to read our 12-page paper 🙂 So, about a year ago we were concerned that web-site administrators are including JavaScript code from remote-sources without too much thinking. This can lead to issues because:

  1. The remotely included code can be buggy and you are thus introducing vulnerabilities to your own site, when you choose to include it
  2. The remote host can be malicious and use its scripts to attack your users and exfiltrate data from your site
  3. The remote host can be targeted by an attacker, as a way of reaching a harder to get target (e.g. your page)

This lead us to conduct the largest, to-date, web crawl with a focus on remote JavaScript inclusions. Based on the top 10,000 Alexa sites, we crawled over 3,300,000 pages and recorded approximately 8.5 million remote inclusions. The findings that I want to share with you, in this blog post are the following:

  1. Even though most sites of the Alexa top 10,000 include code from up to 15 remote hosts, there are sites that include code from up to 295 remote hosts. Assuming that only one of these hosts is enough to fully compromise your script-including site, trusting almost 300 of those is, at the very least, worrisome
  2. As far as remote inclusions as concerned, Google is king, owning 5 out of the top 10 most included scripts found in our study
  3. Certain web-tracking and market-research companies (like addthis.com and scorecardresearch.com) have crept their way into the 10 most popular remotely-included JavaScript scripts. This should raise some eyebrows, since these are sites that most users have never directly visited and are not aware of their existence.
  4. A large percentage of JavaScript providers seem to not be too interested in keeping their software and servers up-to-date. This can be problematic, when a motivated attacker targets them and if you include code from them, they are essentially the weakest link in your security chain.
  5. In our logs of remote JavaScript inclusions, we found the following, previously unknown, vulnerabilities:
    • Script inclusions from locahost: We found over 130 script inclusions which were requesting their “remote” JavaScript from localhost or What this means, is that a user’s browser will try to fetch the necessary JavaScript code from the user’s own machine. Couple this, with multi-user systems, where users have the ability to run web-server processes (think smartphones) and you have a recipe for disaster. A malicious user can poison the vulnerable page by providing malicious JavaScript for all these requests. We called these Cross-User Scripting attacks
    • Script inclusions from private-network IP addresses: Same as above, but now the site tries to include code from hosts such as “”. This means that the attacker now just needs to be in the same local network (Cross-network Scripting).
    • Script inclusions from non-registered domains: This is one of my favorites. We found 56 domains that were supposedly providers for JavaScript, but they were not registered!!! This means that an attacker can simply register a domain and start providing malicious JavaScript to anyone who requests it. We registered two of these and recorded about 85,000 requests for JavaScript in two weeks! We called these Stale Domain-name-based Inclusions since these are domains that were once full sites and even-though they expired, other sites kept on requesting scripts from them.
    • Script inclusions from non-responding IP addresses: Addressing a remote host directly by its IP address means that if that host gets assigned a new IP address, you should update your records. We found some interesting cases of sites requesting JavaScript from IP addresses that did not even have a web server listening on the appropriate port. While harder to exploit, an attacker who gets hold of a particular IP address will be able to inject code on the victim pages (Stale IP-address-based Inclusions)
    • Script inclusions from typosquatting domains: That’s probably my favorite one 🙂 We found some unregistered domains that were actually mistypes of the intended domain (e.g. googlesyndicatio.com, missing the final n). We realized that the developers messed-up when writing the script inclusion and requested code from the wrong domain. By registering googlesyndicatio.com, we actually recorded more than 163,000 requests for JavaScript in two weeks! This goes to show that developers, like all others, are also prone to misspell domains. These misspellings however have the potential to cause much greater damage than a user’s mistypes in her own browser. We called this attack Typosquatting Cross-site Scripting(TXSS).

In total, we found that there are many ways for an application to be attacked based on a remote JavaScript inclusions. In addition to all the findings mentioned above, we also studied script-inclusions over time and we evaluated the practicality of two straightforward countermeasures, i.e., coarse-grained sandboxing and local script copies, and showed how feasible (or not) is each one, given the current popular scripts of the web.

Check out our full paper for all the juicy details 🙂
Till next time

Nick Nikiforakis

Posted in Paper summaries | 2 Comments

Breaking McAfee’s Social Protection

On my usual daily visit of Slashdot, I read that McAfee introduced a new application called “McAfee Social Protection” for Facebook. In a nutshell, you install their plugin, allow their application to control quite a bit of your Facebook and then you can start uploading pictures “safely”. Here’s a video of it in action.

Continue reading

Posted in Breaking stuff | 8 Comments

Google AdChoices…

They say a picture is worth a thousand words. How about, two pictures?

AdChoices "pledge"

So, the important points of the above text are:

“It’s our goal to make these ads as relevant and useful as possible for you. Google doesn’t create categories, or show ads, based on sensitive topics such as race, religion, sexual orientation, or health.

Sounds reasonable. Let’s see the ad that actually got me here.

An AdSense ad about dating, based on religion, while watching a video-clip from a popular Christian band

One can claim that the ad is targeting single people, but it is actually targeting the intersection of Christian and Single, thus effectively targeting both.

Google, don’t be evil.


Posted in Miscellanea | 3 Comments

To Google Chrome: Relax less…

I’ve been recently reading Michal Zalewski’s “The Tangled Web”, a book which tries to map the whole security landscape around browsers and Web applications in about 300 pages… it does a pretty good job 🙂

Now, in Chapter 9, he talks about “Content Isolation Logic” and in one specific section he touches on the document.domain property of the DOM of a page. So, in short, when two pages, foo.example.com and bar.example.com want to communicate through JavaScript, by default they cannot since the Same Origin Policy allows accesses only when the protocol, domain and port fully match. Since, “foo.example.com” !== “bar.example.com” the check fails and thus the domains can’t communicate. Since this is somewhat too rigid, a developer can choose to relax the domain of his page from foo.example.com to example.com. In JavaScript, this is a simple assignment to the document.domain property: Continue reading

Posted in Breaking stuff | 1 Comment

El cheapo hosting, le open redirect…

Did you know that if you use a popular cheap web hosting product and you haven’t changed the default error pages of your sites, you are most likely hosting an open redirect? If not, read on 🙂

Suppose for a second that you are a loyal customer of babyhow.com, an eshop selling stuff for your baby. One beautiful day you receive an email letting you know that babyhow.com has moved its business and providing you with a link to read more:

Continue reading

Posted in Breaking stuff | Leave a comment