Security Blog

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

Automating web application security testing

16 iulie 2007
Share on Twitter Share on Facebook
Google

23 de comentarii :

Philipp Lenssen spunea...

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?

16 iulie 2007 la 16:45
Alex spunea...

Is Lemon going to be available to the public?

16 iulie 2007 la 17:21
Akuma spunea...

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.

16 iulie 2007 la 17:25
.mario spunea...

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

16 iulie 2007 la 17:48
pdp spunea...

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.

16 iulie 2007 la 18:03
Javier Mendoza spunea...

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!

16 iulie 2007 la 21:01
Pogo spunea...

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

Any chance of this happening?

17 iulie 2007 la 14:02
Unknown spunea...

> 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.. :/

17 iulie 2007 la 18:13
Andres Riancho spunea...

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

18 iulie 2007 la 21:04
Unknown spunea...

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

Hong

22 iulie 2007 la 04:09
Unknown spunea...

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.

23 iulie 2007 la 17:28
Mastishka spunea...
Acest comentariu a fost eliminat de autor.
27 iulie 2007 la 13:20
Mastishka spunea...

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...

27 iulie 2007 la 13:21
antispam96 spunea...
Acest comentariu a fost eliminat de administratorul blogului.
21 august 2007 la 23:09
Unknown spunea...
Acest comentariu a fost eliminat de administratorul blogului.
30 septembrie 2007 la 11:13
Unknown spunea...

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.

30 septembrie 2007 la 11:21
ae spunea...

@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?

1 octombrie 2007 la 15:39
ae spunea...

@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

1 octombrie 2007 la 15:58
Unknown spunea...

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

11 noiembrie 2007 la 01:14
COYOTE spunea...

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

12 martie 2008 la 06:37
Ron spunea...
Acest comentariu a fost eliminat de administratorul blogului.
23 martie 2008 la 10:25
Unknown spunea...

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.

4 septembrie 2009 la 09:45
Priti spunea...

Is Lemon open for contribution from the Open Source Community?

27 iulie 2014 la 22:19

Trimiteți un comentariu

  

Etichete


  • #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
    • mai
    • apr.
    • mar.
    • feb.
    • ian.
  •     2024
    • dec.
    • nov.
    • oct.
    • sept.
    • aug.
    • iul.
    • iun.
    • mai
    • apr.
    • mar.
    • feb.
    • ian.
  •     2023
    • dec.
    • nov.
    • oct.
    • sept.
    • aug.
    • iul.
    • iun.
    • mai
    • apr.
    • mar.
    • feb.
    • ian.
  •     2022
    • dec.
    • nov.
    • oct.
    • sept.
    • aug.
    • iul.
    • iun.
    • mai
    • apr.
    • mar.
    • feb.
    • ian.
  •     2021
    • dec.
    • nov.
    • oct.
    • sept.
    • aug.
    • iul.
    • iun.
    • mai
    • apr.
    • mar.
    • feb.
    • ian.
  •     2020
    • dec.
    • nov.
    • oct.
    • sept.
    • aug.
    • iul.
    • iun.
    • mai
    • apr.
    • mar.
    • feb.
    • ian.
  •     2019
    • dec.
    • nov.
    • oct.
    • sept.
    • aug.
    • iul.
    • iun.
    • mai
    • apr.
    • mar.
    • feb.
    • ian.
  •     2018
    • dec.
    • nov.
    • oct.
    • sept.
    • aug.
    • iul.
    • iun.
    • mai
    • apr.
    • mar.
    • feb.
    • ian.
  •     2017
    • dec.
    • nov.
    • oct.
    • sept.
    • iul.
    • iun.
    • mai
    • apr.
    • mar.
    • feb.
    • ian.
  •     2016
    • dec.
    • nov.
    • oct.
    • sept.
    • aug.
    • iul.
    • iun.
    • mai
    • apr.
    • mar.
    • feb.
    • ian.
  •     2015
    • dec.
    • nov.
    • oct.
    • sept.
    • aug.
    • iul.
    • iun.
    • mai
    • apr.
    • mar.
    • feb.
    • ian.
  •     2014
    • dec.
    • nov.
    • oct.
    • sept.
    • aug.
    • iul.
    • iun.
    • apr.
    • mar.
    • feb.
    • ian.
  •     2013
    • dec.
    • nov.
    • oct.
    • aug.
    • iun.
    • mai
    • apr.
    • mar.
    • feb.
    • ian.
  •     2012
    • dec.
    • sept.
    • aug.
    • iun.
    • mai
    • apr.
    • mar.
    • feb.
    • ian.
  •     2011
    • dec.
    • nov.
    • oct.
    • sept.
    • aug.
    • iul.
    • iun.
    • mai
    • apr.
    • mar.
    • feb.
  •     2010
    • nov.
    • oct.
    • sept.
    • aug.
    • iul.
    • mai
    • apr.
    • mar.
  •     2009
    • nov.
    • oct.
    • aug.
    • iul.
    • iun.
    • mar.
  •     2008
    • dec.
    • nov.
    • oct.
    • aug.
    • iul.
    • mai
    • feb.
  •     2007
    • nov.
    • oct.
    • sept.
    • iul.
    • iun.
    • mai

Feed

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