cgisecurity.com · Domains · Slashdot Mirror

No relevant results for "around". by tepples · 2012-08-30 08:09 · Score: 1 · on Google Talks About the Dangers of User Content

Google around.

around didn't provide relevant results.

But with the literal-minded housekeeper costume off, forge referer and spoof referer still don't. This page is from 2006, and this page likewise explains a flaw that has since been fixed. This page claims that it's possible to forge a referer in the visitor's browser using redirection, but only from a domain that the attacker controls. This result claims that the only way is to get the user to install a plug-in: "If you want to redirect a visitor to another website and set their browser's referer to any value you desire, you'll need to develop a web browser-plugin or some other type of application that runs on their computer. Otherwise, you cannot set the referer on the visitor's browser." A bunch of results were links to such plug-ins, but the viewer is likely to decline the plug-in installation. What am I missing?

Cross-site Scripting FAQ by mrkitty · 2011-09-21 10:30 · Score: 1 · on Adobe Pushes Emergency Flash Player Security Fix

Cross-site Scripting FAQ http://www.cgisecurity.com/xss-faq.html

What is your computer setup? by TheOtherChimeraTwin · 2011-09-12 04:32 · Score: 4, Interesting · on Kevin Mitnick Answers

KM: You send me yours along with the IP address, and I'll tell you mine. Good try at information reconnaissance.

Oh please. The poor fanboy just wanted to have the same setup you are using. From your visit to Atlanta in 2008:

"In his luggage, they found a MacBook Pro, a Dell XPS M1210 laptop, an Asus 900 mini-laptop, three or four hard drives, numerous USB storage devices, some Bluetooth dongles, three iPhones, and four Nokia cell phones (with different SIM cards for different countries).
They also found a lock-picking kit and an HID proximity card spoofer that can be used to snag data stored on physical access cards by swiping it in front of them. The data can then be used to enter locked doors without having to make a forged access card. Mitnick says he used the device in a demonstration about security in his speech in Bogota, but that the customs agents' eyes lit up when they saw it, thinking it was a credit card reader.

(Source: Kevin Mitnick Detained in Atlanta for having computer equipment on flight)

The XSS FAQ by Anonymous Coward · 2011-03-28 09:21 · Score: 0 · on McAfee's Website Full of Security Holes

http://www.cgisecurity.com/xss-faq.html

The Cross-site Scripting (XSS) FAQ by mrkitty · 2010-10-04 05:12 · Score: 4, Informative · on Geolocation XSS Tracker Proof of Concept

The XSS FAQ
http://www.cgisecurity.com/xss-faq.html

The Cross-site Scripting FAQ and Resources by mrkitty · 2010-04-13 04:46 · Score: 1 · on Apache Foundation Attacked, Passwords Stolen

XSS FAQ
http://www.cgisecurity.com/xss-faq.html

WASC Threat Classification - Cross-site Scripting
http://projects.webappsec.org/Cross-Site+Scripting

Re:maybe someone would leak how they did it by Jah-Wren+Ryel · 2010-04-07 09:09 · Score: 1 · on How Did Wikileaks Do It?

Would the leak about how the leak happened be hosted on wikileaks, or do we need a WikiLeaksLeaks?

They would host it.

They hosted a leak of their own donor list.

Re:What kept them? by 68kmac · 2010-03-20 05:23 · Score: 1 · on Mozilla Plans Fix For Critical Firefox Vulnerability In Next Release

Lynx is pretty secure

Even Lynx has had security issues. While searching for an example, I found this, which is even better ;-)

Sounds like the cause could be by mrkitty · 2010-01-07 10:00 · Score: 1 · on Hotmailers Hawking Hoax Hunan Half-Offs

A CSRF vulnerability?

More info by mrkitty · 2009-07-11 04:41 · Score: 0 · on ImageShack Hacked, Security Groups Threatened

@ http://www.cgisecurity.com/2009/07/antisec-hackers-replace-all-imageshack-images.html

Re:XSS (Cross-Site Scripting) definition? by jc42 · 2009-06-30 06:32 · Score: 1 · on New Firefox Standard Aims to Combat Cross-Site Scripting

Note the difference between your definition and mine. My definition (shared by everyone else) involves three computers:

Actually, that's not shared by quite everyone else. I just followed the link in another post, to the cgisecurity.com site's FAQ. I should perhaps remark that I was rather embarrassed to read some of what's there. But note that it's from a company that is clearly pushing itself as an expert on web security.

If you read the "What is Cross Site Scripting?" section, you'll probably have a hard time pointing to anything that mentions three or more computers. I don't read that anywhere in the paragraph. Later on, there are a couple of sketchy example that would probably involve three machines, but even then, it's not clear that that's a critical detail. What does seem clear is that they aren't presenting a 3-machine setup as a significant part of what they're defining.

Also, the string "sandbox" doesn't occur in their FAQ. In fact, not even "san" was found by firefox. So their definition doesn't require 3 machines or a sandbox.

Actually, their "definition" is rather remarkable for its vagueness. I suspect that this page was written (or more likely, re-written) by marketers and/or tech writers who don't understand the topic, and probably don't care to. But that's beside the point, because this is the FAQ on "Cross Site Scripting" [their capitalization] of a company whose business is web security. What they have on that page is what they present to visitors as how they understand and define the topic.

This is yet another entry in my list of incompatible definitions of the phrase at hand. I think that the phrase has been co-opted by the marketers, sorta like "virus" and "hacker" and other scary-sounding technical terms. So, while we can talk about it all we like, chances are that the folks reading slashdot all have their own definitions, most of which are as confused as this one. And we'd have a lot of trouble finding two definitions that are even close to the same, even from people presenting themselves as web-security experts.

It reminds me of Bertrand Russell's famous description of mathematics as a subject in which "we never know what we're talking about nor whether what we're saying is true". That's a fun quote to bring up when people are discussing whether Computer Science is a branch of mathematics. If it really were, then we CS types should be happy to embrace (and extend) Russell's characterization.

The XSS FAQ by mrkitty · 2009-06-29 10:33 · Score: 2, Informative · on New Firefox Standard Aims to Combat Cross-Site Scripting

The Cross-site Scripting (XSS) FAQ http://www.cgisecurity.com/xss-faq.html

We have no history by QuoteMstr · 2009-05-21 07:16 · Score: 4, Insightful · on The Future Might Be BIOS and Browsers

We repeat the same lessons every generation, don't we?

We have our own terrible business languages, our own non-relational databases*, our own stupid development fads, our own overwrought RPC protocol, our own profoundly ignorant ways to "disable" things for the user, our own wasteful incompatibilities, our own locked-down propretiary platforms, and the same casual disregard for proper security.

This industry has no sense of its own history. Instead of benefiting from the innumerable hours past programmers spent solving universal problems, we ignore and reject their work, and with only a few exceptions, we spend countless hours solving solved problems.

By the time we work through the mess, another generation of programmers will have rejected our work, and will be well on the way to repeating the cycle. It's depressing as hell.

(Come to think of it, I don't think I've ever written a post that offended so many software developers simultaneously.)

* RDBMs systems didn't come first; people started using them over navigational databases for good reasons that still apply today.

The XSS FAQ by mrkitty · 2009-04-12 04:45 · Score: 2, Informative · on Twitter Gets Slammed By the StalkDaily XSS Worm

The Cross-site Scripting FAQ http://www.cgisecurity.com/xss-faq.html

Re:Well by smoker2 · 2009-01-18 07:07 · Score: 1 · on Windows 7's Media Hype Having the Opposite Effect As Vista's

Do you have a copy of an "infected" php file we can look at ? Or a link that describes the same issue happening to others ? Because it seems more likely that it was due to third party banners or a XSS attack. I assume you are on a shared server, so the reinstall was probably either a clean virtual machine image or your chrooted environment was wiped and replaced. Who else on the same machine had these issues ? You realise that a lot of php apps are attacked by cracking the apps admin passwords not by rooting the server. And if your pc got 0wned then any saved passwords on it might have been sent off to a remote site as well.

Mind you, your server management guys probably made some cash out of you. And you put the same software back on straight away .... cool. Either way, you have not demonstrated that linux had anything to do with this. PHP maybe, the php app itself more likely. Are you blaming windows for the acrobat issue ?

Re:Hanlon's Razor by Fruit · 2008-09-29 20:22 · Score: 1 · on CSRF Flaws Found On Major Websites, Including a Bank

Option 2 is not going to work:

Can CSRF be prevented by implementing referrer checking?

No. Referer headers can be spoofed using XMLHTTP and by using flash as demonstrated by Amit Klein and rapid7 and therefore cannot be trusted.

(From The Cross-Site Request Forgery (CSRF/XSRF) FAQ.)

On an unrelated note: whenever you check referrers, please allow for missing referrer headers so that I don't need to make my browser lie to you.

Re:Wouldn't a referer check also counter this? by pavon · 2008-09-29 17:27 · Score: 1 · on CSRF Flaws Found On Major Websites, Including a Bank

The referrer can be spoofed using javascript (XMLHttpRequest), and thus cannot be depended on even with trusted browsers.

The Cross-site request forgery FAQ by mrkitty · 2008-09-29 14:31 · Score: 4, Informative · on CSRF Flaws Found On Major Websites, Including a Bank

http://www.cgisecurity.com/articles/csrf-faq.shtml

Additional Information by mrkitty · 2008-06-06 08:07 · Score: 5, Informative · on Mozilla Experiments With Site Security Policy

This is something a lot of us in the industry have been writing about. Here's my rant from last October Browser Security: I Want A Website Active Content Policy File Standard!
http://www.cgisecurity.com/2007/11/08

Jeremiah Grossman's thoughts
http://jeremiahgrossman.blogspot.com/2008/06/site-security-policy-open-for-comments.html

Additional Information by mrkitty · 2008-05-27 11:00 · Score: 3, Informative · on TJX Fires Employee For Disclosing Vulnerability

http://www.cgisecurity.com/2008/05/11

The Cross-site Scripting FAQ by mrkitty · 2008-04-19 12:33 · Score: 3, Informative · on Major ISPs Injecting Ads, Vulnerabilities Into Web

http://www.cgisecurity.com/articles/xss-faq.shtml

SQL Injection and Blind SQL Injection Info by mrkitty · 2007-08-12 05:08 · Score: 2, Insightful · on United Nations vs SQL Injections

http://www.cgisecurity.com/questions/sql.shtml
http://www.cgisecurity.com/questions/blindsql.shtm l

Many other papers on the subject
http://www.cgisecurity.com/development/sql.shtml

SQL Injection and Blind SQL Injection Info by mrkitty · 2007-08-12 05:08 · Score: 2, Insightful · on United Nations vs SQL Injections

http://www.cgisecurity.com/questions/sql.shtml
http://www.cgisecurity.com/questions/blindsql.shtm l

Many other papers on the subject
http://www.cgisecurity.com/development/sql.shtml

SQL Injection and Blind SQL Injection Info by mrkitty · 2007-08-12 05:08 · Score: 2, Insightful · on United Nations vs SQL Injections

http://www.cgisecurity.com/questions/sql.shtml
http://www.cgisecurity.com/questions/blindsql.shtm l

Many other papers on the subject
http://www.cgisecurity.com/development/sql.shtml

Re:URL referrer by idontgno · 2007-06-29 07:06 · Score: 1 · on Major Flaw Found In Security Products

In the context I'm talking about, the browser has no control over the referrer.

Review TFA and read the pretty-good Wikipedia article about Cross-Site Request Forgery.

Then imagine a Javascript program, uploaded to a victim's browser by your hypothetical shadyhackerswebsite. (The victim's looking for instructions for how to cut down the size of his window shades and got fooled by a seeded Google response, let's say.)

The Javascript takes advantage of the breach in document security which is the subject of TFA: if the brower the Javascript is running in has another window or tab open, and that tab (for instance) is authenticated into a trusted web-form-based site (like online banking), the Javascript can take advantage of the authenticated state of the other session to submit a form URL to the target website.

So, you say that referrer checking should safeguard that, because the white-hat browser session (doing real e-banking business, for instance) would have a valid referrer URL in the form submission but the black-hat Javascript can't.

This latter assertion (the Javascript can't synthesize the referrer) is wrong. Read http://www.cgisecurity.com/lib/XmlHTTPRequest.shtm l to see how to spoof a referrer string in a Javascript-based GET or POST.

Now, are you arguing that maybe the browser's HTTP interface should be intervening by validating any outbound referrer? That isn't happening. I don't know the mechanics of Javascript implementations in browsers, particularly in reference to the HTTP interface of the browser engine itself, but I'm guessing that they're independent and the browser has very little supervisory control over what Javascript is doing with the XmlHTTPRequest method. In other words, the browser will play by the referrer rules, but Javascript isn't obligated to.

By the way, to some extent I'm simply speculating, but the experts have already spoken. Read http://www.cgisecurity.com/articles/csrf-faq.shtml , and note well the following question/answer:

Can CSRF be prevented by implementing referrer checking?
No. Referer headers can be spoofed using XMLHTTP and by using flash as demonstrated by Amit Klein and rapid7 and therefore cannot be trusted.

And yes, it's a bug. The real bug is the stupid conceit that HTTP can be stateful, first and foremost. You can hack at it and create state with cookies and the like, but if browser software can send valid information then crafted mobile malware can send invalid information and break state and get away with it.