Security Blog

The latest news and insights from Google on security and safety on the Internet

Automating web application security testing

July 16, 2007
Share on Twitter Share on Facebook
Google

23 comments :

Philipp Lenssen said...

Thanks for the explanations.

In a future post, can you explain how you limit the damage an XSS exploit cookie stealer on *.Google.com can do? E.g. if an XSS hole is found at groups.google.com (these things have been found in the past), how do you ensure it can't easily spread to mail.google.com -- if that's even possible if you want to keep a single sign on via Google Account?

July 16, 2007 at 4:45 PM
Alex said...

Is Lemon going to be available to the public?

July 16, 2007 at 5:21 PM
Akuma said...

If you talk about XSS you rearly should have mentioned the "XSS Cheat Sheet". You can pull it up with a Google search for that term, since i did not want to post the URL here ;-)
It shows a lot more attack vectors.

July 16, 2007 at 5:25 PM
.mario said...

Automated scanning will never be able to replace manual testing but it's a good and fast approcach to catch "low hanging fruits".

If you are looking for more advanced vectors I recommend the xssDB hosted on GNUCITIZEN. The vectors from the XSS Cheat Sheet will find their way in the next days as well as some XSS injection verctors of mine.

http://www.gnucitizen.org/xssdb/

Also we will add SQL injection vectors later.

I am very interested in contributing to the Lemon project so if you need some manpower just drop me a line.

Greetings,
.mario

July 16, 2007 at 5:48 PM
pdp said...

What about DOM-based XSS. This type of vector is quite common and extremely hard to detect. I don't think that there is a tool that can handle it at the moment.

The XSSDB can be used in many different ways. Since it is community driven I guess you might be interested in consuming the feed into your Lemon tool to provide finner results.

July 16, 2007 at 6:03 PM
Javier Mendoza said...

Just a question, after reading this I understand that Lemon is a testing box, with some scripts, programs and so to test the pages weakness to a XSS attack. I think this is great, but what about, apart from this, using a layer 7 firewall in front of the servers?

At least here in Spain, these kind of boxes are not very common, although they filter HTTP request pretty well...

Just my 2 cents, and sorry for my English!

July 16, 2007 at 9:01 PM
Pogo said...

I'd like to know if Lemon is ever going to be released to the public.

Any chance of this happening?

July 17, 2007 at 2:02 PM
Unknown said...

> What about DOM-based XSS. This type
> of vector is quite common and
> extremely hard to detect. I don't
> think that there is a tool that can
> handle it at the moment.

As long as they will not do javascript static/functional analysis, tool will not be able to test for this.
And I don't think it will come by tomorrow.. :/

July 17, 2007 at 6:13 PM
Andres Riancho said...

Shameless plug!

I have been working on a web application attack and audit framework for some time, maybe you guys would like to see it . Many things make w3af a great project: gpl, coded in python, extended using plugins and much much more!. The site is:

http://w3af.sf.net

July 18, 2007 at 9:04 PM
Unknown said...

I don't think your suggestion for preventing XSS can avoid the "Injection inside URL attributes - non-http(s) URL" XSS vlun.

Hong

July 22, 2007 at 4:09 AM
Unknown said...

While I recognize you have to start somewhere, there is little to no support from Google when your account has been compromised. You fill out a plain and simple Google form with no reccord or confirmation number issued. No promise of a response in 5 business days, etc., just soon as possible. With the billions you make, maybe next Google should try to buy a company who knows how to offer good customer service, and offer a tinely response to customers who don't know what to do, or where to turn and are anxious because thousands have been taken out of their accounts. Maybe they will get it back, but really its rather disappointing you can't even send a confirmation email to let us know you really did get the email and that its not "crawling" around somewhere in cyberspace.

July 23, 2007 at 5:28 PM
Mastishka said...
This comment has been removed by the author.
July 27, 2007 at 1:20 PM
Mastishka said...

I own a website and had a Google AdSense account. In the early days when I was getting information about earning money via my website, I came to know about Google AdSense. As an analyst I am always curious about what is happening behind the scenes, so I went through the AdSense ad generator code which can be easily download from Google's server, which they used to generate Ads.

To know more about PPC model of advertisement I had gone through number of articles/reports on Pay Per Click mechanism including the report of Dr. Tuzhilin (Professor of Information Systems at the Stern School of Business at New York University), who evaluated Google’s invalid click detection efforts (Find PDF Report [Source: http://ebiquity.umbc.edu/blogger/2006/07/25/revealed-how-google-manages-click-fraud/]).

After going through all those articles and analyzing Google’s code I found a way to simulate human behavior in click generation and page impressions in proper (acceptable) ratio from different geographic location (IP address) and was able to credit thousands of dollars in my AdSense account (By not a single human being generated click).

So, do you realy think they are really having good things with them???

Contact me at lalit.arora@mgoos.com if you like to know more...

July 27, 2007 at 1:21 PM
antispam96 said...
This comment has been removed by a blog administrator.
August 21, 2007 at 11:09 PM
Unknown said...
This comment has been removed by a blog administrator.
September 30, 2007 at 11:13 AM
Unknown said...

I am posting this message on behalf of Ishita Gureck who has profile on Orkut ,But facing problem because some intrudder,mischief people has create her two more profile with same name and details also has joined illegal communities from her fake profile.
Her original profile has more than 100 scraps.

but the fake two has 50 and 3 scraps respectively..when you search using ISHITA GURECK search option...there may be few political resons...We have well verified with details..I request to delete the same to avoid any further infeltration....Please help urgent..Is there any way to avoid any else to do such illegal act...Its major concern.

September 30, 2007 at 11:21 AM
ae said...

@mario -- re: Human analysis -- it's interesting you say this. As we refine tests at WhiteHat, I get to measure percentages of vulnerability.

e.g.- many classes of our XSS detection have a 99.9something% accuracy rate, and require almost no human validation.

Others can drop as low as 40% accuracy, but as we learn with time we can streamline what to look for, variances, and document them, and the net results is that finding locations weak to XSS in over 600 hosts better than any "scanner" isn't that hard.

@pdp -- DOM-based XSS: Um, we do this fairly well with WhiteHat Sentinel. We, like all the scanners, have a "DOM-based parser" as well as static analysis, but we have some tricks in automation, with humans added, that allow us to find this.

@hong -- Attribute-based XSS. Done. Solved. Sentinel scanner, above.

Took a while though.

@GOS blog -- You realize the whole XSS problem isn't just a "javascript injection problem"? There's many other ways to find this, not to mention you have livescript, actionscript, mocha, vbscript, and good old HTML that presents issues.

Take the image source tag -- the majority of modern browsers will not execute js directly in the src= tag, nor using the js embedded-as-an-image trick. Older IE, Opera, and some moz versions.

Here's a handful of simple examples:
http://www.anachronic.com/xss/

I'm curious if Google has a "protect our top browsers" or "protect all browsers" stance?

October 1, 2007 at 3:39 PM
ae said...

@GOS blog -- re: recommendations, also one more BIG thing:

Converting CRLF to \r\n can be really dangerous depending on when, where, and how it's done.

In many, many applicatons folks do this wrong and you wind up with exploitable applications because \r\n lands somewhere in the headers, most commonly URI data, like a name-value pair, passed in the Location Header on a 302 redirect, but sometimes in a cookie with user-supplied value as well.

This can give you full control of the HTTP Response, in addition to opening up some dangerous cache-poisoning attacks that are very hard to detect and measure.

-ae

October 1, 2007 at 3:58 PM
Unknown said...

what about url encoded attacks? u have not covered tht :-p

November 11, 2007 at 1:14 AM
COYOTE said...

excuse me......
but am i the only one who is ennoyed from this eye test every time i want to search something on google??
anyway if the way stays like this, i'm sure not only me, a lot of google users would transfer to yahoo or others. Because it is ennoying

March 12, 2008 at 6:37 AM
Ron said...
This comment has been removed by a blog administrator.
March 23, 2008 at 10:25 AM
Unknown said...

To make automatic test for WEB site vulnerabilities I use CyD NET Utilities. The latest version has a new testing engine. Sometimes the program make mistakes but work fine and fast.

September 4, 2009 at 9:45 AM
Priti said...

Is Lemon open for contribution from the Open Source Community?

July 27, 2014 at 10:19 PM

Post a Comment

  

Labels


  • #sharethemicincyber
  • #supplychain #security #opensource
  • android
  • android security
  • android tr
  • app security
  • big data
  • biometrics
  • blackhat
  • C++
  • chrome
  • chrome enterprise
  • chrome security
  • connected devices
  • CTF
  • diversity
  • encryption
  • federated learning
  • fuzzing
  • Gboard
  • google play
  • google play protect
  • hacking
  • interoperability
  • iot security
  • kubernetes
  • linux kernel
  • memory safety
  • Open Source
  • pha family highlights
  • pixel
  • privacy
  • private compute core
  • Rowhammer
  • rust
  • Security
  • security rewards program
  • sigstore
  • spyware
  • supply chain
  • targeted spyware
  • tensor
  • Titan M2
  • VDP
  • vulnerabilities
  • workshop


Archive


  •     2025
    • May
    • Apr
    • Mar
    • Feb
    • Jan
  •     2024
    • Dec
    • Nov
    • Oct
    • Sep
    • Aug
    • Jul
    • Jun
    • May
    • Apr
    • Mar
    • Feb
    • Jan
  •     2023
    • Dec
    • Nov
    • Oct
    • Sep
    • Aug
    • Jul
    • Jun
    • May
    • Apr
    • Mar
    • Feb
    • Jan
  •     2022
    • Dec
    • Nov
    • Oct
    • Sep
    • Aug
    • Jul
    • Jun
    • May
    • Apr
    • Mar
    • Feb
    • Jan
  •     2021
    • Dec
    • Nov
    • Oct
    • Sep
    • Aug
    • Jul
    • Jun
    • May
    • Apr
    • Mar
    • Feb
    • Jan
  •     2020
    • Dec
    • Nov
    • Oct
    • Sep
    • Aug
    • Jul
    • Jun
    • May
    • Apr
    • Mar
    • Feb
    • Jan
  •     2019
    • Dec
    • Nov
    • Oct
    • Sep
    • Aug
    • Jul
    • Jun
    • May
    • Apr
    • Mar
    • Feb
    • Jan
  •     2018
    • Dec
    • Nov
    • Oct
    • Sep
    • Aug
    • Jul
    • Jun
    • May
    • Apr
    • Mar
    • Feb
    • Jan
  •     2017
    • Dec
    • Nov
    • Oct
    • Sep
    • Jul
    • Jun
    • May
    • Apr
    • Mar
    • Feb
    • Jan
  •     2016
    • Dec
    • Nov
    • Oct
    • Sep
    • Aug
    • Jul
    • Jun
    • May
    • Apr
    • Mar
    • Feb
    • Jan
  •     2015
    • Dec
    • Nov
    • Oct
    • Sep
    • Aug
    • Jul
    • Jun
    • May
    • Apr
    • Mar
    • Feb
    • Jan
  •     2014
    • Dec
    • Nov
    • Oct
    • Sep
    • Aug
    • Jul
    • Jun
    • Apr
    • Mar
    • Feb
    • Jan
  •     2013
    • Dec
    • Nov
    • Oct
    • Aug
    • Jun
    • May
    • Apr
    • Mar
    • Feb
    • Jan
  •     2012
    • Dec
    • Sep
    • Aug
    • Jun
    • May
    • Apr
    • Mar
    • Feb
    • Jan
  •     2011
    • Dec
    • Nov
    • Oct
    • Sep
    • Aug
    • Jul
    • Jun
    • May
    • Apr
    • Mar
    • Feb
  •     2010
    • Nov
    • Oct
    • Sep
    • Aug
    • Jul
    • May
    • Apr
    • Mar
  •     2009
    • Nov
    • Oct
    • Aug
    • Jul
    • Jun
    • Mar
  •     2008
    • Dec
    • Nov
    • Oct
    • Aug
    • Jul
    • May
    • Feb
  •     2007
    • Nov
    • Oct
    • Sep
    • Jul
    • Jun
    • May

Feed

Follow
Give us feedback in our Product Forums.
  • Google
  • Privacy
  • Terms