Below is a list of some of my favorite tools to use for hacking android applications. Each one has its particular usefulness and can be fun to use. Most of them are open source projects so feel free to reach out to the developers on Github to ask for help or even contribute. I’ve found it that they are very helpful.

  1. Android SDK
    • This is a must have for obvious reasons
    • Main SDK used to interact with android. Particular tools of interest are Android Debug Bridge (ADB) and AAPT.
    • Used to gain shell access to a device. Allows for an array of actions via command line.
  2. Android Backup Extractor
    • Used to extract android application backups. Apps with the flag allowBackups=”true” in their AndroidManifest.xml can be backed up. The backup will include information such as preferences, the APK itself, and any database files that are stored on that application. This often times contains PII and passwords, unfortunately.
    • Backups will not retrieve data for an application that is on external storage. You will have to access the external storage separately to access any data that may be stored outside of the application’s context.
    • Doesn’t work very well if the device has encryption turned on. Depends on the device.
  3. APK Tool
    • Used to decompile an APK and commonly used for reverse engineering.
    • Useful for looking for hardcoded passwords or encryption keys when source code is not available.
    • You can look at the resulting android manifest file to see which services and activities can be called. Checking for restrictions can be useful.
    • Check resulting android manifest file for any particular URIs that an application accepts. It may be an entry point.
  4. Fastboot
    • Used to manipulate partitions on the device
    • Let’s you reset partitions and also flash the device with other images.
    • Keep in mind that flashing the system partition does NOT remove the app partition where application data is stored. This can be useful when working with an Mobile Device Management (MDM) where the MDM is installed on the system partition and prevents access at the App partition level. If you flash the system partition, the MDM will be gone and you’ll have unrestricted access to data on the App partition.
  5. Burp Suite Pro
    • Favorite proxy tool for anything really
    • Keep in mind that some applications use WebSockets so keep an eye on that tab
    • When proxying Android apps, you may need to accept other MIME types that aren’t on by default.
  6. OWASP Dependency Check
  7. Dex2Jar
    • When reverse engineering an android APK, you can use this tool to get the java code for the outputs provided by the APK tool above.
    • This can also be used to decompile an APK, modify it, and then re-package it. Keep in mind this will ruin the signature of the APK but it will remain the same otherwise.
    • Can be buggy
  8. SQLite Database Browser
  9. Towel Root
    • Used to root Android devices. Can root just about anything except for a few I’ve already reported to the developer.
    • Root access = game over 99% of the time.

I am at an interesting point in my life. I am transitioning from being in a consulting role to becoming CTO of a Payments/Bitcoin startup. This prospect is both extremely exciting and a bit terrifying at the same time.

I have also been working on making myself more of a well-rounded individual. Since my rising interest in Bitcoin, I have become increasingly interested in the world of finance, entrepreneurship, and dare I say…politics (gross). I was recommended a book written by Ben Horowitz, the ex CEO and a very successful VC and entrepreneur. After googling the first chapter and reading it, I decided to buy the book.

There were many things in Ben’s early life that I could personally relate to so the book was an easy and entertaining read for me. For example, we both come from very humble beginnings. My family and I are refugees from Bosnia that had to start from scratch after moving to the states. My parents were 40 years old at the time and I don’t know about you, but I can’t imagine moving somewhere at 40 with only what you could pack into a suitcase and starting over – never mind being successful (all with young children and not speaking a lick of English). Ben mentions his parents being card-carrying communists which was particularly interesting to me since I was born in communist Yugoslavia and I always noticed how my parents were affected having grown up in that form of government. When I was growing up in Kentucky my father would always ask me if I had my “documents” every time I ventured outdoors to play with my friends. There were many other similarities that I won’t go into but the one thing I believe is that when you don’t come up in a privileged environment, you have to grow up fast and be able to adapt very quickly. This definitely seems to be a theme throughout Ben’s book.

The book goes through Ben’s version of the crazy roller coaster ride that is the venture capital lifestyle that’s so prevalent in Silicon Valley. What really keeps you on the edge of your seat is the insane number of choices a CEO has to make regularly that could mean the life or death of the company. The book also highlights how the leadership position is a very lonely place. The CEO often makes decisions and they are never popular with everyone. The book goes into many of the tougher decisions that a leader has to make whether it’s firing a close friend or a manager that has significant influence at the company. What I really liked about this book is that there weren’t any chapters that I read and thought the content was common sense. Ben did a great job of cutting out the bullshit and providing the reader with content that really matters.

Overall I think the book is a great read no matter who you are. I’ve seen multiple reviews that criticize the book by saying that it’s geared toward CEO’s and other top level executives. I whole-heartedly disagree because to me the book has great advice on how to be a leader and how to take responsibility when being put in a position where your decisions affect those around you. My only criticism is that I would have liked to read more examples of failures that Ben and others in the industry have had and how they have successfully recovered from them.

I would definitely recommend the read.

Amazon Link to Book
Annotated First Chapter on
Ben’s Twitter


This past weekend I attended the Hackers of Planet Earth (HOPE) conference in New York City (

There were over 90 scheduled talks and most of them were pretty amazing. Here are some of my highlights.

Edward Snowden and Daniel Ellsberg Keynote

The keynote was packed with people! I managed to get a seat near the back about 2 hours before the keynote and when I looked behind me a few minutes later there were a sea of people who were overflowing into the other room. They announced that people were piling out the doors on the first floor of the hotel so that they can see the feed on the first floor. Amazing. I was also amazed at just how little BO there was considering the audience.

Snowden and Ellsberg had a great conversation about where they see the whistleblowing going in the future. Ellsberg wanted to get the point across that more people in the government and corporate industries should take the risk and leak information. Snowden was more focused on enabling these people to leak information and stay anonymous at the same time so they don’t go into exile like himself. I personally don’t have an opinion on this since I tend to focus more on the technology and try to steer clear of the politics. However, I cannot imagine everyday people risking their families, lives, and friends to leak information that may not be nearly as earth-shattering as Snowden’s leaks.

Identifying Back Doors, Attack Points, and Surveillance Mechanisms in iOS Devices

This was one of the most interesting talks to me. The speaker did a great job of showing some real security concerns about the IOS security infrastructure. Apple has put in many back doors to exfiltrate data from devices that are locked and assumably encrypted. Most IOS users think their data is encrypted on their device with either their PIN or fingerprint if they have one of the newer IOS devices. But it’s not.

Apple puts this back door to get data out of a device in the event a company person is deceased which makes sense. If this is used by the wrong people, the feature can be very dangerous. I am definitely re-visiting my stance on IOS vs Android security after this talk. The Google Play Store may be full of malware but at least Google isn’t putting back doors into my device. How do I know this? Because Android is open source!

North Korea – Using Social Engineering and Concealed Electronic Devices to Gather Information in the World’s Most Restrictive Nation

I only have two words for this talk. Simply Amazing. The speaker did an absolutely amazing job presenting his findings that he gathered from his multiple trips to North Korea. I’ve been following the North Korea stories pretty closely so I wasn’t really expecting to learn anything new. Man, was I wrong. The DPRK is basically a country of 24 million people who are willing to die at a moment’s notice for some crazy guy. Every morning, propaganda is played as people wake up, go to work, as they work, and before they go to sleep. The only television is NK TV that’s on a couple hours a day. The radios in homes do not have dials for stations (they can never be entirely turned down either) and those that do, unapproved frequencies are jammed by the government.

I will continue to watch the fascinating events that unfold in North Korea. The shit in the country will eventually hit the fan and we’ll all watch in fascination as millions of brainwashed people have to adapt to the world around them. If they survive.


A few minutes ago, Ben Lawsky from NYDFS released the Proposed BitLicense Regulatory Framework. I’m sure lots of very smart lawyers, regulators, and finance folks will have a thorough analysis of the proposal. However, I wanted to check it out to see how this proposal would affect virtual currency related implementations for engineers.

There is no doubt that this will affect business and regulatory requirements for many Bitcoin software and hardware startups. So lets look at some of the points.

Anti Money Laundering & Cyber Security

  1. Provide for independent testing for compliance with, and the effectiveness of, the anti-money laundering program to be conducted by qualified personnel of the Licensee or by a qualified outside party, at least annually – This will affect almost every Bitcoin based business. Engineers will have to implement a robust logging and auditing feature that monitors all their business’ transactions so that at the end of the year they can provide a complete log of what went on. There are many security implications for this. For one, this will most likely contain Personally Identifiable Information (PII) and will have to be kept safe. I could see potential businesses popping up just to provide this service for Bitcoin companies.
  2. Provide ongoing training for appropriate personnel to ensure they have a fulsome understanding of anti-money laundering requirements – Yeah, that won’t happen anywhere. If it does, it will be some e-learning program that everyone forgets within minutes of watching it. But hey, that’s compliance!
  3. Records of Virtual Currency transactions. Each Licensee shall maintain the following information for all transactions involving the payment, receipt, exchange or conversion, purchase, sale, transfer, or transmission of Virtual Currency: the identity and physical addresses of the parties involved, the amount or value of the transaction, including in what denomination purchased, sold, or transferred, the method of payment, the date(s) on which the transaction was initiated and completed, and a description of the transaction – This is a doozie. I think this is what will give companies the most headache. The two that give me the most pause is the fact that you have to have the physical address of the parties involved and a description of the transaction. It basically means that if you’re a BitLicense holder and you’re doing business with a person or entity, they not only have to provide you with their address but also a description of what the transaction is for. We’re already seeing this added at companies like Coinbase where whenever you take BTC out of your wallet, they ask you where it’s going. It seems quite intrusive to me and might turn away many people from Bitcoin. On the technical side of things, engineers will have to make sure that the data they collect is valid and compensate for the fact that transactions just went from simply putting in a Bitcoin address and hitting send to having to provide physical addresses and detailed descriptions. How do you validate these descriptions? There will need to be a protocol or system in place that allows merchants and businesses to whitelist Bitcoin addresses and that leads to a huge privacy issue in itself.
  4. Each Licensee shall file Suspicious Activity Reports – This is hard. Engineering this can be a total nightmare. There will be a lot of false positives and Bitcoin startups will struggle to keep up with the customer relations nightmare this might cause.
  5. Each Licensee shall establish and maintain an effective cyber security program to ensure the availability and functionality of the Licensee’s electronic systems and to protect those systems and any sensitive data stored on those systems from unauthorized access, use, or tampering. – Thank you Jesus! This is probably the most important aspect of this entire section. Unfortunately Fortune 500 businesses fail miserably at this, what makes us think Bitcoin startups with college dropouts for Engineers can do it? I actually have more faith in them than I do in the financial industry.
  6. Each Licensee shall designate a qualified employee to serve as the Licensee’s Chief Information Security Officer (“CISO”) – This is a neat idea. This expense will be huge for small Bitcoin companies. They simply cannot afford penetration tests, code reviews, and other items in this section. A huge amount of their funding may have to be spent on security which in turn might reduce time to market significantly if not done extremely efficiently.

Overall thoughts

I think NYDFS definitely took a lot of caution when writing this. It’s a thin line for sure because if they are too strict with their framework it will drive innovation and jobs out of the state and possibly this country. As a New York resident, I’m not terribly disappointed by the proposal. It seems doable. The simple fact of the matter is that most people will have no issue adhering to this BitLicense. None of the items seem to be any more intrusive than the credit card industry and the merchants still get the benefit of irreversible transactions that protect them from chargebacks and fraud.

Engineers will have their work cut out for them as they should. The security items outlined in the proposal are robust. While it will definitely increase cost from both a staffing and infrastructure perspective, it will encourage Bitcoin companies to think about security before something bad happens. Frameworks will have to be put in place to secure, audit, and monitor all virtual currency activity in an organization. This will be tough at first but I think services and tools will become available to aid businesses in doing this.

I think the Bitcoin community is innovative enough to find cost effective solutions to meet all these proposed regulations in a way that does not stifle innovation too much. However, I also think that the process to meet these regulations will “separate the men from the boys” when people start thinking about starting a Bitcoin business.

You can view the full thing here:


I get a lot of people asking me about the proper way to do cold storage of their Bitcoins. These are commonly folks who are building a Bitcoin startup and are taking preventative measures. I like to think these are the people that will be successful. Unlike Mt. Gox and many other Bitcoin startups who neglect to think about their customers.

Anyway, I’ve devised a scheme for this on the Bitcoin Security Project organization that I run. In my security engineer duties I’ve had to design many secure architectures and I certainly think that this is one of them. If you disagree, contact me.

The scheme is a multi-tier architecture that I believe to be suitable for small to large Bitcoin companies. The basics are simple:

  1. Keep only a small amount in hot storage that wouldn’t ruin you if you lose it.
  2. Require strong authorization and authentication from multiple people when moving Bitcoin between tiers.
  3. Give some training to the folks who have control of your Bitcoin, please.
  4. Use common sense and do not automate withdrawal from cold storage. Servers get hacked all the time ya know.

Below is the scheme if you’re too lazy to check out the link above.

Multi Tiered Cold Storage Solution


The Aegis Bitcoin Wallet

I’ve been using Bitcoin for a couple of years now. It’s gone from a curiosity to somewhat of an obsession. Anyway, my mobile device of choice is an Android and I haven’t been able to find a wallet that I can use and trust at the same time. So I decided to create one.

I designed it from the ground up for security. Lots of help was given by the guys at especially in the NFC department. They also did an awesome job coordinating and coming through on the UI design. Admittedly, I am more of an engineer and definitely not a UI designer.

The wallet has a ton of features. For security, it encrypts all keys that are on the device. In order to send money, you either have to provide a password or an NFC tag that has an encryption value stored on it.

You can download the wallet at the play store or you can visit the site here:

You can check out the code on github at Please contribute if you can. All help is appreciated.

Aegis Home Screen


It’s been a while since my last post and many things have changed. I’ve started a new job at an awesome place, moved to New York City, learned a ton, and even made a second Android app.

It’s called (after much deliberation) Android Security Score and it does some stuff I haven’t seen other security apps do. It analyzes all the installed apps as well as all important security settings of an Android device. It then gives the user a simple score (A-F) that a person can use to get an idea of where their device is in terms of security.

Here’s some other stuff it does:

  1. Provide the user with permissions an app requests
  2. Give advice on how to make their device more secure/improve their score
  3. List potentially dangerous third party apps
  4. Root detection
  5. Showing apps that are old and out of date
  6. And several other things I can’t think of right now

It can be downloaded from

And if you want the PRO version, which includes a handy dandy PDF report of all your results, you can get it from this here link.

Without further ado, here are some screenshots.

If you have any ideas for improvement or features you’d like to see, please let me know!






This is another installment of using Aspect Oriented Programming techniques to mitigate common vulnerabilities in Java web applications.

First let’s define Cross Site Request Forgery (CSRF) – From OWASP:

CSRF is an attack which forces an end user to execute unwanted actions on a web application in which he/she is currently authenticated. With a little help of social engineering (like sending a link via email/chat), an attacker may force the users of a web application to execute actions of the attacker’s choosing. A successful CSRF exploit can compromise end user data and operation in case of normal user. If the targeted end user is the administrator account, this can compromise the entire web application.

Lets say you have this scenario:

You work on an super important Java web app with bunches of servlets, controllers, actions, JSP’s, etc…
You just learned how CSRF could be a huge threat to your users and you want to implement code for mitigating it on every POST request throughout.

The problem here is that to implement mitigating measures the ‘ol fashioned way, you have to go to every JSP and put in a CSRF token into every form that gets submitted. After that, you have to validate the token and put a new one up.

Using the technique below, you can mitigate CSRF without having to do any significant leg work. Here’s how!
Note: this is assuming you have AspectJ installed as well as Tomcat 6+

1. First you have to set the AspectJ weaver Java agent to the JVM parameter of your Tomcat startup. This is typically in your /bin/ in your installation folder.

Add this to the JAVA_OPTS: -javaagent:C:/aspectj1.6/lib/aspectjweaver.jar (my path)

2. Second, you have to create a couple of aspects. I put these in a com.aspects package under the src folder.

Aspect 1: MitigateCSRFAspect – This aspect will create a pointcut that will intercept all POST requests to the application. Once it does that, it will put a CSRF token on the request and a matching one on the users’ session. It will also validate any CSRF token parameters. Props to Mr. Ricardo Zuasti for his post on some of this stuff.

package com.aspects; 
import java.util.concurrent.TimeUnit;

import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

import org.apache.commons.lang.RandomStringUtils;
import org.apache.log4j.Logger;

import com.thesis.aop.util.StopWatch;
public aspect MitigateCSRFAspect{ 
	Logger logger; 
	StopWatch watch;
	//Constuctor for the Aspect. I do some init of loggers and
	//such here.
	public MitigateCSRFAspect(){ 
		logger = Logger.getLogger("csrfMitigationLogger");"CSRF Prevention Aspect Created"); 
		watch = new StopWatch(); 
	pointcut csrf_interceptDoPost(HttpServletRequest req, 
		HttpServletResponse resp) :
			execution(* doPost(HttpServletRequest, 
				HttpServletResponse)) && args(req, resp);
	//This is the Advice for the above pointcut definition. 
	//It intercepts the response and request parameters.
	Object around(HttpServletRequest req, 
			HttpServletResponse resp): 
		csrf_interceptDoPost(req, resp){
		watch.start();"Inside of MitigateCSRF Advice");
		//Validation of salt currently on the request
		String saltFromRequest = 
			(String) req.getParameter("csrfSalt");
			Cache<String, Boolean> csrfCacheFromRequest = 
				(Cache<String, Boolean>)
		//If cache on session is not there, then it must be 
		//the first request. Therefore there would be no 
		//csrf token that exists yet.
		if(csrfCacheFromRequest != null){
	        if (saltFromRequest != null &&
	        	getIfPresent(saltFromRequest) != null){
	            // If the salt is in the cache, we move on
"SALT IS GOOD! " + saltFromRequest);
	        } else {
	            // Otherwise we log an error
	  "CSRF detected! Engage panic mode.");
		//Setting the new salt
		Cache<String, Boolean> csrfCache = (Cache<String, Boolean>)
        if (csrfCache == null){
        	csrfCache = CacheBuilder.newBuilder()
                .expireAfterWrite(30, TimeUnit.MINUTES)
        	"Setting csrfCache: " + csrfCache);
            req.getSession().setAttribute("csrfCache", csrfCache);
        String salt = RandomStringUtils.random(20, 0, 0, 
        		true, true, null, new SecureRandom());
        csrfCache.put(salt, Boolean.TRUE);
        //Use this on the JSP"Setting CSRF Salft: " + salt);
        req.setAttribute("csrfSalt", salt);
		watch.stop(); + 
			"_" + thisJoinPoint.getSourceLocation().getLine() + 
			"," + watch.getElapsedTime());	
		//This passes in the response object with the new header and
		//continues application execution flow as normal. 
		return proceed(req, resp);

Aspect 2: JSPCSRFTokenInjection – This aspect will intercept the JspWriter.write and the _jspService  methods. It will take the csrfToken value from the request and stick it in every single form on the page.

package com.aspects; 
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import javax.servlet.jsp.JspWriter;

import org.apache.log4j.Logger;

import com.thesis.aop.util.StopWatch;
public aspect JSPCSRFTokenInjection{ 
	Logger logger; 
	StopWatch watch;
	private String currentCSRFToken = null;
	//Constuctor for the Aspect. I do some init 
	//of loggers and such here.
	public JSPCSRFTokenInjection(){ 
		logger = Logger.getLogger("csrfMitigationLogger");"CSRF Injection Aspect Created"); 
		watch = new StopWatch(); 
	//Capturing the CSRF Token from the request 
	//by intercepting the 
	//_jspService method inside of the JSP
	public pointcut csrf_jspServiceIntercept(HttpServletRequest req, 
		HttpServletResponse resp) : 
	    execution(* *._jspService(HttpServletRequest, 
	    && args(req, resp);
	before(HttpServletRequest req, HttpServletResponse resp) : 
		csrf_jspServiceIntercept(req, resp){
		currentCSRFToken = (String) req.getAttribute("csrfSalt");"Got CSRF Token from request: " 
				+ currentCSRFToken);
	//Pointcut and advice for capturing the writing into a JSP.
	public pointcut csrf_captureFormWriting(String msg) :
		call(public void JspWriter.write(String)) 
		&& args(msg) 
		&& if(msg.toLowerCase().contains("</form>"));

	Object around(String msg) : csrf_captureFormWriting(msg){
		msg = msg.replace("</form>", "<input type='hidden' " +
				"name='csrfSalt' value='" 
				+ currentCSRFToken + "'/></form>");"MSG Value: " + msg);
		return proceed(msg);

3. After that, you have to create an XML file that will map your aspects to the files you want to weave at load time. This file will be located in your applications classes folder under a META-INF directory. In my case it was WebGoat/WebContent/WEB-INF/classes/META-INF/aop-ajc.xml

		<aspect name="com.aspects.MitigateCSRFAspect"/>
		<aspect name="com.aspects.JSPCSRFTokenInjection"/>

4. Compile and Run your application using AJDT or the AspectJ compiler and see the results below. I used the OWASP WebGoat application to test this out. As you can see below in the log files, the CSRF token is being put on the request, put into the JSP’s, taken off the request, and validated.


579022 [http-8080-2] INFO  csrfMitigationLogger  :: Inside of MitigateCSRF Advice
579022 [http-8080-2] INFO  csrfMitigationLogger  :: SALT IS GOOD! nLcD6Y02xmy7JprdeEgO
579023 [http-8080-2] INFO  csrfMitigationLogger  :: Setting CSRF Salft: DdEeErMfxOuugPkm3x4Z
579023 [http-8080-2] INFO  csrfMitigationLogger  :: HammerHead.java_120,1
579026 [http-8080-2] INFO  csrfMitigationLogger  :: Got CSRF Token from request: DdEeErMfxOuugPkm3x4Z
579030 [http-8080-2] INFO  csrfMitigationLogger  :: MSG Value:         </select><input type=’hidden’ name=’csrfSalt’ value=’DdEeErMfxOuugPkm3x4Z’/></form>

579068 [http-8080-2] INFO  csrfMitigationLogger  :: Got CSRF Token from request: DdEeErMfxOuugPkm3x4Z
580649 [http-8080-2] INFO  csrfMitigationLogger  :: Got CSRF Token from request: DdEeErMfxOuugPkm3x4Z
580651 [http-8080-2] INFO  csrfMitigationLogger  :: MSG Value:             <input type=’hidden’ name=’csrfSalt’ value=’DdEeErMfxOuugPkm3x4Z’/></form>

583787 [http-8080-2] INFO  csrfMitigationLogger  :: Inside of MitigateCSRF Advice
583788 [http-8080-2] INFO  csrfMitigationLogger  :: SALT IS GOOD! DdEeErMfxOuugPkm3x4Z
583788 [http-8080-2] INFO  csrfMitigationLogger  :: Setting CSRF Salft: plZJegGquQaFzcxmjBxX
583789 [http-8080-2] INFO  csrfMitigationLogger  :: HammerHead.java_120,2
583834 [http-8080-2] INFO  csrfMitigationLogger  :: Got CSRF Token from request: plZJegGquQaFzcxmjBxX
583836 [http-8080-2] INFO  csrfMitigationLogger  :: MSG Value:         </select><input type=’hidden’ name=’csrfSalt’ value=’plZJegGquQaFzcxmjBxX’/></form>

583876 [http-8080-2] INFO  csrfMitigationLogger  :: Got CSRF Token from request: plZJegGquQaFzcxmjBxX
583876 [http-8080-2] INFO  csrfMitigationLogger  :: Got CSRF Token from request: plZJegGquQaFzcxmjBxX
583877 [http-8080-2] INFO  csrfMitigationLogger  :: MSG Value:             <input type=’hidden’ name=’csrfSalt’ value=’plZJegGquQaFzcxmjBxX’/></form>

587996 [http-8080-2] INFO  csrfMitigationLogger  :: Inside of MitigateCSRF Advice
587996 [http-8080-2] INFO  csrfMitigationLogger  :: SALT IS GOOD! plZJegGquQaFzcxmjBxX
587997 [http-8080-2] INFO  csrfMitigationLogger  :: Setting CSRF Salft: Kwct0YrzeGSVEkb9YzGp
587997 [http-8080-2] INFO  csrfMitigationLogger  :: HammerHead.java_120,2
588017 [http-8080-2] INFO  csrfMitigationLogger  :: Got CSRF Token from request: Kwct0YrzeGSVEkb9YzGp
588022 [http-8080-2] INFO  csrfMitigationLogger  :: MSG Value:         </select><input type=’hidden’ name=’csrfSalt’ value=’Kwct0YrzeGSVEkb9YzGp’/></form>

588073 [http-8080-2] INFO  csrfMitigationLogger  :: Got CSRF Token from request: Kwct0YrzeGSVEkb9YzGp
588075 [http-8080-2] INFO  csrfMitigationLogger  :: Got CSRF Token from request: Kwct0YrzeGSVEkb9YzGp
588091 [http-8080-2] INFO  csrfMitigationLogger  :: MSG Value:                         <input type=’hidden’ name=’csrfSalt’ value=’Kwct0YrzeGSVEkb9YzGp’/></form></td>

588104 [http-8080-2] INFO  csrfMitigationLogger  :: MSG Value:                         <input type=’hidden’ name=’csrfSalt’ value=’Kwct0YrzeGSVEkb9YzGp’/></form>

588115 [http-8080-2] INFO  csrfMitigationLogger  :: MSG Value:                         <input type=’hidden’ name=’csrfSalt’ value=’Kwct0YrzeGSVEkb9YzGp’/></form>

592720 [http-8080-2] INFO  csrfMitigationLogger  :: Inside of MitigateCSRF Advice
592720 [http-8080-2] INFO  csrfMitigationLogger  :: SALT IS GOOD! Kwct0YrzeGSVEkb9YzGp
592721 [http-8080-2] INFO  csrfMitigationLogger  :: Setting CSRF Salft: 9ojOc5YNuYyPAC6LZ0Ak
592721 [http-8080-2] INFO  csrfMitigationLogger  :: HammerHead.java_120,1
592731 [http-8080-2] INFO  csrfMitigationLogger  :: Got CSRF Token from request: 9ojOc5YNuYyPAC6LZ0Ak
592736 [http-8080-2] INFO  csrfMitigationLogger  :: MSG Value:         </select><input type=’hidden’ name=’csrfSalt’ value=’9ojOc5YNuYyPAC6LZ0Ak’/></form>

Let me know if you have questions and I’ll gladly answer them.



Clickjacking, also known as a “UI redress attack”, is when an attacker uses multiple transparent or opaque layers to trick a user into clicking on a button or link on another page when they were intending to click on the the top level page. Thus, the attacker is “hijacking” clicks meant for their page and routing them to other another page, most likely owned by another application, domain, or both.

The recommended solution to fixing this is to add the X-FRAME-OPTIONS header value, SAMEORIGIN. This is simple enough. BUT! What if you want to make the change application wide without having to go through hundreds or possibly thousands of files of source code?

This is where AOP and AspectJ in particular can be leveraged to prevent such vulnerabilities. The solution I came up with is to intercept the doGet and doPost calls in the entire application and creating an advice to “wrap” each of these calls. The wrapping would add the necessary header value and than continue the application execution as normal.

Basically what happens here is the Aspect created will weave in code to add the X-FRAME-OPTIONS header in any place that a doPost or doGet call is made.

What I did to show that this works is take the OWASP WebGoat project and test it out.

First, I created the aspect and placed it in the project. It looks like this:

package com.aspects; 
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

import org.apache.log4j.Logger;
import org.apache.log4j.PropertyConfigurator;

import com.thesis.aop.util.StopWatch;
public aspect ClickJackingAspect{ 
	Logger logger; 
	StopWatch watch; 
	//Constuctor for the Aspect. I do some init of loggers and
	//such here.
	public ClickJackingAspect(){ 
		logger = Logger.getLogger("clickJackingLogger");"Click Jacking Prevention Aspect Created"); 
		watch = new StopWatch(); 

	//Pointcut definition for the doGet method.
	// Notice I'm intercepting all calls to doGet and specifying the 
	// request and response parameters.
	pointcut clickJacking_addHeaderDoGet(HttpServletRequest req, 
		HttpServletResponse resp) : 
		execution(* doGet(HttpServletRequest, 
			HttpServletResponse)) && 
		args(req, resp);
	//This is the Advice for the above pointcut definition. 
	//It intercepts the response and request parameters.
	Object around(HttpServletRequest req, HttpServletResponse resp): 
		clickJacking_addHeaderDoGet(req, resp){
		//Adding the header to the response object
		resp.addHeader( "X-FRAME-OPTIONS", "SAMEORIGIN" ); 
		watch.stop(); + 
			"_" + thisJoinPoint.getSourceLocation().getLine() + 
			"," + watch.getElapsedTime());			
		//This passes in the response object with the new header and
		//continues application execution flow as normal. 
		return proceed(req, resp);
	//Below is the same as above but for the doPost method.
	pointcut clickJacking_addHeaderDoPost(HttpServletRequest req, 
		HttpServletResponse resp) : 
		execution(* doPost(HttpServletRequest, HttpServletResponse)) 
		&& args(req, resp);
	Object around(HttpServletRequest req, HttpServletResponse resp): 
		clickJacking_addHeaderDoPost(req, resp){

		resp.addHeader( "X-FRAME-OPTIONS", "SAMEORIGIN" ); 
		watch.stop(); + 
		thisJoinPoint.getSourceLocation().getLine() + "," + 
		return proceed(req, resp);

Second, I compiled the project using the AspectJ Compiler and tested it out. I used the Tamper Data plugin for Firefox to verify that the new header was on every response (Click thumbnail):



There you have it! Under 50 lines of code (which is very little considering this is Java) and clickjacking is mitigated in your web application. Feel free to contact me with any questions and good luck!



My thesis on “Eliminating SQL Injection and Cross Site Scripting Using Aspect Oriented Programming” (I know, it’s a mouthful) has been approved for publishing!

Click this to download if you’re interested in the whole thing.

If anyone wants to discuss it, feel free to contact me. I’d love to hear your ideas.

I hope to further develop it to mitigate some of the other items in the OWASP top 10 in the near future and port it out to a few other programming languages besides Java.


Cross Site scripting (XSS) and SQL injection are two of the most common vulnerabilities found in applications. According to a study done by the Web Application Security Consortium (WASC) on 12,186 web applications, the percentage of sites with these vulnerabilities is 38 and 13 percent, respectively [3]. The fundamental reason these vulnerabilities exist in web applications are critical design flaws which lead to security issues across entire projects. It is typical in the case of web applications that developers continue to write insecure code and only fix these issues when they are noticed or become a problem [4]. Using Aspect Oriented Programming (AOP), modules can be created to address these security vulnerabilities across an entire application without modifying existing source code. This paper will explain in detail how the use of AOP and AspectJ in particular can be leveraged to create a tool for eliminating these two major security vulnerabilities in open source Java web applications. The implications of a tool for successfully eliminating these vulnerabilities would lead to a significant improvement in web application security by uncovering fundamental design flaws, providing sanity checks for programmers and architects, and make applications compliant with PCI DSS Standard with respect to XSS and SQL Injection.


Older Posts »