There is a small risk of an unknown bug — or a known but unpatched one — in your mail client allowing an attack by just viewing a message.
I think, though, that this very broad advice is also given as a defense against some types of phishing scams. Social engineering attacks are common and can lead to serious trouble. Making sure people are at least ...
A good option is to harden your Content Security Policy. It allows you to fine-tune which resources the browser will load/run, and is supported by most browsers.
Consider the following header:
Content-Security-Policy: default-src 'none'; img-src 'self'; style-src 'self';
This tells the browser to disable scripts, frames, connections and any other objects/...
Firefox (fixed in Nightly 59.0a1), Safari (fixed in Safari Technology Preview 54), Edge, and Internet Explorer display an authentication dialog if you request an image and the server asks that you authenticate with HTTP Basic authentication. This allows an attacker to display an authentication dialog when a user's browser tries to load the image:
This is actually a real concept, "Self XSS" which is sufficiently common that if you open https://facebook.com and then open the developer tools, they warn you about it
Obviously Facebook is a specific type of target and whether this issue matters to you or not, would depend on the exact nature of your site, but you may not be able to discount the idea of ...
Below are the things an attacker can do if there is XSS vulnerability.
Ad-Jacking - If you manage to get stored XSS on a website, just
inject your ads in it to make money ;)
Click-Jacking - You can create a hidden overlay on a page to hijack clicks of the victim to perform malicious actions.
Session Hijacking - HTTP cookies can be accessed
Like Anders says: Blender makes a very good point about authentications dialogs, and multithr3at3d is right about the on attributes. Moreover, Anders add argues about the a tag and Matija have a good link about exploiting libraries doing the rendering.
Yet, no one talked about SVG yet.
First of all let's assume that all input and output is properly ...
First of all, your security guy is likely right. It doesn't look like you have anything to worry about because from your description of the issue and the guy's response I think that the script tags were properly encoded. Think of it as a neutralized weapon. It's there, yes, but it cannot do any damage.
Running that code through a deobfuscator gives us
First, linking a session to an IP address will not make it secure since the server could see many different users as using the same IP address for various reasons (all types of proxy servers, for instance: client, reverse proxy, CDN, etc.).
Second, the same user could very well use different IP addresses for the same session. For instance, someone could be ...
The idea would be that different parts of the server code interpret the request in different ways, resulting in an application that is vulnerable to HTTP Parameter Pollution.
For your example /editpost/?postuid=19348&postuid=1 the query string would be parsed differently for the code parts that carry out authorization (those would have to check for ...
From a developer's perspective, the first two points you have are not very relevant. Stored and Reflected XSS have the same mitigation: properly escape things you output according to their context. Layers of defense will likely only be viewed as an excuse for poorly implementing this mitigation: "The WAF will catch it for me."
Instead, focus on these code ...
This way you escape from a double-quoted attribute (") and close the previous tag (>) before opening a script tag that contains your payload. It's one of the most basic XSS patterns.
<input type="text" value="$XSS">
With your sequence it becomes:
<input type="text" value=""><script>alert(document.cookie)</script>">
^- a completed ...
Am I being overly paranoid or do I have a genuine concern?
You have a genuine concern. Something is not right here.
Is it normal for a gateway provider to obfuscate their code like this?
Obfuscation is not, all by itself, abnormal. However, at the point they're trying to open localhost connections to RDP, VNC, and other ports, that's not ...
In a cross-site request forgery attack, the attacker tries to force/trick you into making a request which you did not intend. This could be sending you a link that makes you involuntarily change your password. A malicious link could look like that:
In a cross-site scripting attack, the attacker ...
Not for gmail, but for Outlook there have been a number of "preview pane" exploits where simply looking at the email is enough to compromise: Can malware be activated by previewing email in Outlook's Preview pane?
Plaintext injection is an issue. Say you have a page template that looks like this:
Blah blah blah.
And you can inject from the URL.
An attacker can construct an email with a link to www.example.com/ajax/ads.asp?name=Foo%2C+you+have+the+wrong+version+Flash+plugin%2C+our+company+policy+requires+that+you+use+version+vul.ne.rabl.e.%0D%0A%...
There used to be a "vulnerability" where the image could send a HTTP 401 Unauthenticated response, which would trigger a login screen for the user. If you set this as forum avatar, it would spawn a login popup for anyone visiting a page where your avatar appears. Lots of people will then attempt to log in with some username and password combination, probably ...
“Sanitisation” is an unhelpful and misleading term. There are two different animals here:
Output escaping. This is an output-stage concern. When you take variable strings and inject them into a larger string that has a surrounding syntax, you must process the injected string to make it conform to the requirements of that syntax. What exactly that processing ...
Yes, DOM-based XSS is still a concern. While some issues cannot be exploited due to URL encoding, there a number of situations where URL encoding will not stand in the way of exploitation.
The gist of the example is to form a hashbang query with injection
That's one example, but DOM-based XSS encompasses all XSS issues that result from insecurely ...
" onfocus="alert(1)" autofocus="
It will expand to:
<input type="text" id="search-text" name="query" value="" onfocus="alert(1)" autofocus="" />
Which will cause an alert box, demonstrating XSS.
TL;DR: How does CORS prevent XSS? It does not. It is not meant to do so.
CORS is intended to allow resource hosts (any service that makes its data available via HTTP) to restrict which websites may access that data.
Example: You are hosting a website that shows traffic data and you are using AJAX requests on your website. If SOP and CORS were not there, ...
So let's say you navigate to www.example.com/page?main.html and it puts you on the main page of example.com. Now you navigate to the index, which is located at www.example.com/page?index.html. You start to wonder, what other pages are there?
So you type in www.example.com/page?foo and hit enter, and you get an error page which will say something like "...
In jQuery you can specify a CSS selector and HTML code with the same shorthand.
This is a selector:
This is HTML that gets evaluated immediately:
This is a real-life code sample for parsing a selector from the location hash (the URL part after a #):
var x = $('#' + window.location.hash.substr(1));
First, a definition from Chrome:
Same-site cookies (née "First-Party-Only" (née "First-Party")) allow servers to mitigate the risk of CSRF and information leakage attacks by asserting that a particular cookie should only be sent with requests initiated from the same registrable domain.
So what does this protect against?
The note on whitelisting the data protocol which is referenced says
data: Allows data: URIs to be used as a content source. This is insecure; an attacker can also inject arbitrary data: URIs. Use this sparingly and definitely not for scripts.
This is not in a part specific to the risks of data uris in images, and I have not seen any substantiative ...
Although you are right in that it might not matter so much from an attack point of view. From a usability point of view, the user might come across some 'unexpected behavior'. A while ago I used to have to work with software that had an obvious SQL injection problem (contractors couldn't/wouldn't fix it). This meant that unexpecting users would enter in ...
That depends on what you mean by "inside". For example, as Conor Mancone suggested, there could be a combined reflected XSS and SQL injection. That could look like this:
http://example.com/badendpoint?q=<script>$('input').value="';DELETE FROM USERS;--";$('form').submit()</script>
In this example, the SQL injection is the ...
I propose the following four step program, where you first pick the low hanging fruit to give you some minimum of protection while you work on the bigger problems.
1. Activate client side filtering
1.1 Set the X-XSS-Protection header
Setting the following HTTP response header will turn on the browsers built in XSS protection:
X-XSS-Protection: 1; mode=block