Hot answers tagged xss
42
XSS - Cross Site Scripting (but not limited to actual cross site scripting)
XSS is usually presented in 3 different ways:
Non-persistent (often called reflected XSS)
This is when you are able to inject code and the server returns it back to you, unsanitized. Often this can be exploited by distributing an (usually innocent looking) URL in some form or ...
21
Very wrong, the basic form of XSS is Reflected XSS, where the payload is sent in the URL (for example) from the victim himself.
This is most commonly used in phishing attacks, where the attacker crafts the malicious link, and mails it in social engineering attacks to his victims, or posts it on public forums, etc.
In general XSS has nothing to do with ...
20
SQL injection. If you use Django's object-relational mapper (ORM) layer, you are basically protected from SQL injection.
The only caveat is that you need to avoid manually forming SQL queries using string concatenation. For instance, do not use raw SQL queries (e.g., raw()). Similarly, do not use the extra() method/modifier to inject raw SQL. Do not ...
18
Short answer. Yes, blocking requests with an off-site Referer: header might have some security benefits, but I do not recommend that you implement it. The usability costs are significant and outweigh any security benefits.
I feel that, as security professionals, our job is not just to recommend defenses that people should implement -- it is also to ...
17
Found it
http://sla.ckers.org/forum/read.php?24,33349
http://security.bleurgh.net/javascript-without-letters-or-numbers
http://sla.ckers.org/forum/read.php?24,28687
Converter to convert normal JS into brackets only JS:
http://utf-8.jp/public/jjencode.html
16
I agree with @Jorn's answer about the validation.
However, you're still forgetting a very important step here, and that is output encoding.
E.g. HTML encoding (or Attribute encoding, or Javascript encoding, etc) before outputting anything... In fact, this is arguably even more important than the input validation (arguably, not absolutely, and definitely ...
16
To prevent XSS you need to:
Validate all user input that you'll process (for example - if id GET parameter should be a number, ensure it is with e.g. PHP's is_number() function or using Filter extension). This should not only include GET / POST parameters, but also cookie names, cookie values, HTTP headers, uploaded file names etc. Attackers can manipulate ...
14
There is always the OWASP top ten web vulnerabilities list
A little summary of each from OWASP's report:
Injection - Injection flaws, such as SQL, OS, and LDAP injection, occur when untrusted data is sent to an interpreter as part of a command or query. The attacker’s hostile data can trick the interpreter into executing unintended commands or accessing ...
14
Quoted from OWASP's CSRF Prevention page:
Double Submit Cookies
Double submitting cookies is defined as sending the session ID cookie in two different ways for every form request. First as a traditional header value, and again as a hidden form value. When a user visits a site, the site should generate a (cryptographically strong) pseudorandom value ...
13
For input validation, I recommend a whitelist approach combined with pass-or-reject. So define what is valid, and accept only valid input, reject everything else.
If you build a rich text editor that sends html to your server, you can use JavaScript to sanitize the input, so that pasting html from Word could end up working. Yet your server won't accept any ...
13
Yes it is vulnerable, but not it the way you suspect. The attacker would not try modify the loaded URL, but to execute the code directly. For example:
$_GET['fname'] = '"+(function(){/*any_code_i_like*/})()+"';
will become:
$.ajax({
url: "http://mywebsite/script?param="+(function(){/*any_code_i_like*/})()+""
and the code will execute even before ...
13
This is a fairly common practice called a web bug, it is the main reason that mail clients do not automatically load external images (the second being to protect you from viewing unwanted spam images that could be unsettling; e.g., pornography).
Basically when you load an email with external images enabled and a link to an image like <img ...
12
JavaScript is a client-side language.
In my professional opinion trusting ANY client-side implementation for added security is a waste of time, and the implementation would be a gross waste of resources.
Your time, and money would be better utilized implementing proper input cleansing and validation on the server-side environment.
11
Its all XSS, its not proper to call it "JavaScript Injection". The XSS vector you are talking about isn't new, and its an interesting one. XSS is an output problem. If you perform the same input validation on all input you'll still have problems with XSS. If you encode or strip all < > characters for every input variable you'll still have huge ...
11
Anything you can do with javascript as the site owner can be done with an XSS attack. That includes modifying the DOM. You could replace an entire page and thus have control of all data into and out of the website. Relatively simple scripts can read cookies and forward session information. That would be like Firesheep at a distance -- impersonating a user by ...
11
Yes, this is a very serious concern when it comes to reading your email via a web browser. In fact gmail has had this happen a few different ways. In a broader sense, XSS within an email could be used to spread an email based worm. The XSS payload has access to your list of contacts and the also the ability to send email as you. This is similar to the ...
10
Answer to the original question: No, it's not a security risk for your employees to use Disqus etc. -- at least, no more than any other form of communication.
Of course, if employees post sensitive corporate information on these systems, then that may harm the corporation's interests. But you could say the same of any other means of communication. ...
10
It depends on the context the injection happens.
Obviously, if the injection happens in the context of an elements content like this one:
<p>Your search for "❌" has returned the following results:</p>
< is required to switch from text to markup. But even here, if you echo user input in a <script>, e.g.:
<script>var search = ...
10
No because you should never allow scripts to be able to access your cookies. Refer to HTTPOnly on the OWASP website.
To prevent people from being able to steal session id's, should XSS be present, you should always set this cookie flag. Your mechanism would not work anymore as it would not be able to access the cookie.
9
To piggy-back on what SteveSyfuhs said, there are many possible malicious ways XSS can be used.
Examples:
One example would be to inject malicious code into a database field. Subsequently, any time that field is displayed to the end-user unsanitized, their browser would execute the code. This is called Persistent/Stored Cross Site Scripting.
Another would ...
9
Of course!
False information could be inserted into a webpage with XSS. Imagine if Microsoft had a giant banner on their front page stating they would shut down the whole company, their shares could drop significantly, just because of a XSS attack, without anyone logging in.
9
Markdown alone would not be sufficient for santizing output, since it allows arbitrary HTML/Javascript input and simply passes it unprocessed.
E.g. this is a valid markdown:
## heading
text
But also this:
## heading
text <script>alert('hello');</script>
From the markdown syntax page:
For any markup that is not covered by Markdown’s ...
9
Yes, almost all HTML tags allow you to declare an event handler. Some of these events could be triggered when the page loads without user interaction:
<img src=x onerror=alert(1) />
Event tags are not the only way to trigger xss:
<a href=javascript:alert(1)>xss</a>
One possilbe solution is to set the Content Security Policy for this ...
9
My immediate reaction to this was not positive, for a few reasons.
Trying to use regex to parse complex language constructs is a bad idea. Regular expressions just aren't suitable for such constructs.
Security through blacklisting is a bad idea because you will always be, by definition, one step behind the attackers. You should use a positive security ...
8
Usually there's not much you can do about vulns in 3rd party components.
Among your options:
Start by upgrading to the latest version. If that fixes it, you're done.
Contact the vendor responsibly, and get a fix from them.
If it's open source, try to patch it yourself - or find someone who did. Just make sure you do it right, and fixing XSS can be ...
8
FCKEditor is a platform-independent text editor for web applications.
This kind of exploit is a reflected XSS attack vector. You can read more about it in this question here: can-anybody-explain-xss.
This is happening because the FCKEditor does not sanitize the input given in the variables, leading the application to reflect the variables back to the ...
8
If you really want to understand XSS, I strongly recommend OWASP's XSS Prevention Cheat Sheet. It's not focused on hacking, it's focused on helping developers prevent these problems in the first place. http://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet
8
HTTPS doesn't prevent stealing cookies, HTTPOnly flag does. I would recommend (if it's possible) to have a library of "widgets" users can include in the page and configure. Then you can just insert the JavaScript code with configured parameters without allowing user to write JavaScript code.
If you enable your users to insert their own JavaScript code, they ...
8
https is all about encryption and ensuring server identity to prevent other people from listening to the traffic. So it does not help at all against malicious JavaScript code within the bounds of the same origin policy.
There is a flag on cookies called httpOnly which prevents simple JavaScript code on modern browser to access the cookie. But this does not ...
8
Cookies only; of course, there's nothing preventing you from this:
if (empty($_SESSION['ip']) {
$_SESSION['ip'] = $_SERVER['REMOTE_ADDR'];
} else {
if ($_SESSION['ip'] != $_SERVER['REMOTE_ADDR']) {
// IP changed
}
}
Note that identifying a user by IP address is only a stopgap measure, and I wouldn't consider it relevant to security - e.g. large ...
Only top voted, non community-wiki answers of a minimum length are eligible
