Security Blog

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

Automating web application security testing

2007年7月16日
Share on Twitter Share on Facebook
Google

23 件のコメント :

Philipp Lenssen さんのコメント...

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?

2007年7月16日 16:45
Alex さんのコメント...

Is Lemon going to be available to the public?

2007年7月16日 17:21
Akuma さんのコメント...

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.

2007年7月16日 17:25
.mario さんのコメント...

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

2007年7月16日 17:48
pdp さんのコメント...

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.

2007年7月16日 18:03
Javier Mendoza さんのコメント...

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!

2007年7月16日 21:01
Pogo さんのコメント...

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

Any chance of this happening?

2007年7月17日 14:02
Unknown さんのコメント...

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

2007年7月17日 18:13
Andres Riancho さんのコメント...

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

2007年7月18日 21:04
Unknown さんのコメント...

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

Hong

2007年7月22日 4:09
Unknown さんのコメント...

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.

2007年7月23日 17:28
Mastishka さんのコメント...
このコメントは投稿者によって削除されました。
2007年7月27日 13:20
Mastishka さんのコメント...

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

2007年7月27日 13:21
antispam96 さんのコメント...
このコメントはブログの管理者によって削除されました。
2007年8月21日 23:09
Unknown さんのコメント...
このコメントはブログの管理者によって削除されました。
2007年9月30日 11:13
Unknown さんのコメント...

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.

2007年9月30日 11:21
ae さんのコメント...

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

2007年10月1日 15:39
ae さんのコメント...

@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

2007年10月1日 15:58
Unknown さんのコメント...

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

2007年11月11日 1:14
COYOTE さんのコメント...

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

2008年3月12日 6:37
Ron さんのコメント...
このコメントはブログの管理者によって削除されました。
2008年3月23日 10:25
Unknown さんのコメント...

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.

2009年9月4日 9:45
Priti さんのコメント...

Is Lemon open for contribution from the Open Source Community?

2014年7月27日 22:19

コメントを投稿

  

ラベル


  • #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
    • 5月
    • 4月
    • 3月
    • 2月
    • 1月
  •     2024
    • 12月
    • 11月
    • 10月
    • 9月
    • 8月
    • 7月
    • 6月
    • 5月
    • 4月
    • 3月
    • 2月
    • 1月
  •     2023
    • 12月
    • 11月
    • 10月
    • 9月
    • 8月
    • 7月
    • 6月
    • 5月
    • 4月
    • 3月
    • 2月
    • 1月
  •     2022
    • 12月
    • 11月
    • 10月
    • 9月
    • 8月
    • 7月
    • 6月
    • 5月
    • 4月
    • 3月
    • 2月
    • 1月
  •     2021
    • 12月
    • 11月
    • 10月
    • 9月
    • 8月
    • 7月
    • 6月
    • 5月
    • 4月
    • 3月
    • 2月
    • 1月
  •     2020
    • 12月
    • 11月
    • 10月
    • 9月
    • 8月
    • 7月
    • 6月
    • 5月
    • 4月
    • 3月
    • 2月
    • 1月
  •     2019
    • 12月
    • 11月
    • 10月
    • 9月
    • 8月
    • 7月
    • 6月
    • 5月
    • 4月
    • 3月
    • 2月
    • 1月
  •     2018
    • 12月
    • 11月
    • 10月
    • 9月
    • 8月
    • 7月
    • 6月
    • 5月
    • 4月
    • 3月
    • 2月
    • 1月
  •     2017
    • 12月
    • 11月
    • 10月
    • 9月
    • 7月
    • 6月
    • 5月
    • 4月
    • 3月
    • 2月
    • 1月
  •     2016
    • 12月
    • 11月
    • 10月
    • 9月
    • 8月
    • 7月
    • 6月
    • 5月
    • 4月
    • 3月
    • 2月
    • 1月
  •     2015
    • 12月
    • 11月
    • 10月
    • 9月
    • 8月
    • 7月
    • 6月
    • 5月
    • 4月
    • 3月
    • 2月
    • 1月
  •     2014
    • 12月
    • 11月
    • 10月
    • 9月
    • 8月
    • 7月
    • 6月
    • 4月
    • 3月
    • 2月
    • 1月
  •     2013
    • 12月
    • 11月
    • 10月
    • 8月
    • 6月
    • 5月
    • 4月
    • 3月
    • 2月
    • 1月
  •     2012
    • 12月
    • 9月
    • 8月
    • 6月
    • 5月
    • 4月
    • 3月
    • 2月
    • 1月
  •     2011
    • 12月
    • 11月
    • 10月
    • 9月
    • 8月
    • 7月
    • 6月
    • 5月
    • 4月
    • 3月
    • 2月
  •     2010
    • 11月
    • 10月
    • 9月
    • 8月
    • 7月
    • 5月
    • 4月
    • 3月
  •     2009
    • 11月
    • 10月
    • 8月
    • 7月
    • 6月
    • 3月
  •     2008
    • 12月
    • 11月
    • 10月
    • 8月
    • 7月
    • 5月
    • 2月
  •     2007
    • 11月
    • 10月
    • 9月
    • 7月
    • 6月
    • 5月

Feed

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