New answers tagged

1

You should not only protect yourself from XSS by scanning HTTP requests for attacks. Such a scan will never be complete, and there will always be some smart tricks that slip through the net. Your first line of defence must always be to properly sanitize untrusted data, so as not to create any XSS vulnerabilities in the first place. For how to do that, see ...


-4

To be short I'd recommend you to download Arachni from here, start arachni_web (the WebUI) and to open the URL which will be displayed before. You will be able to test any web site for many existing problems inclusive XSS. I find Arachni very helpful. UPDATED: If Arachni will find some problem that it will provide detailed instruction how you can reproduce ...


4

The short answer No. This is not safe, and should not be done. In fact, this is the last one of OWASP Top 10: A10. Unvalidated Redirects and Forwards Web applications frequently redirect and forward users to other pages and websites, and use untrusted data to determine the destination pages. Without proper validation, attackers can redirect victims ...


2

To add to what others have said : If you have a set of known URL's to redirect to (that you could map to an identifier), it would be much better to allow only known identifiers in the "redirect" parameter value. Then you can map the identifier to your safe, known, URL. Thanks to such a technique "all your troubles" go away. Of course if the value of ...


3

Current versions of PHP detect and prevent newline injections in the header function, see How to avoid HTTP Header Injection (new lines characters). In older versions pf PHP you could probably do something like login.php?redirect=%0D%0A%0D%0A<script>... Which would break out of the header and result in Location: <script>... And your ...


1

The first vulnerability I can think of is to pass a full URL as an argument that will redirect the user to a fake copy of the site (login.php?redirect=http://malicious.com) Aside from that, I'm sure there are several ways to prevent the redirection from happening and displaying instead malicious HTML/JavaScript. As a general rule, any URL parameter should ...


0

You can just run this code: location.assign("http://www.myapp.com/test/"); I tried (on Chrome), and it reloads the page even if it gets passed the URL you are already on. And of course you can also use any of the tips @mcgyver5 suggests for loading resources with JavaScript.


1

Can you create a bunch of Iframes that each have a src of www.myapp.com/test/5? or a programmatically create a bunch of <img src="www.myapp.com/test/5"> Those iframes might end up being a ddos of the browser instead of the server but the img ones might work. then there is ajax which you should be able to simply call in an endless loop and send ...


3

If you only filter for script tags, yes. For example: <img src="x" onerror="alert(1)" /> Or <div style="position: absolute; top: 0; left: 0; width: 9999px; height: 9999px; z-index: 9999" onmouseenter="alert(1)"></div> Or an infinite number of other vectors. You need to properly filter the entire contents when you write them out to ...


1

My answer got longer than expected, so just to give you the answer: <body onpageshow="alert(1)"> probably works, and if it doesn't, <body onpaonpageonpagonpageonpageshowshoweshowshowgeshow="alert(1)"> will. How to try to bypass a custom filter You say you try to learn how to do is yourself, so here are some first steps I would take: check ...


1

Whether or not the client is vulnerable depends on the version of jQuery and on whether or not they are also loading jQuery migrate. I built this test site a while back, where I test different versions of jQuery against two of these bugs: http://research.insecurelabs.org/jquery/test/ Retire.js (free open source tool maintained by me) will tell you if the ...


-1

The Chrome XSS Auditor can be bypassed using the following scripts: 1) http://vulnerable_site?pageTitle=<a href="data:text/html,your xss payload">xss 2) http://vulnerable_site?pageTitle=<a href="data:text/html;base64,base 64 encoded format of your xss payload">xss


0

Conserning POST and GET A link allows GET request when it is clicked. A form allows GET or POST requests when submitted. All GET requests that can be done with a form can also be done with a link and vice versa, so the extra functionality that the form allows is the POST requests. Asuming people stick to the intentions of the HTTP verbs, a POST requests ...


2

A form is more dangerous because it hides more stuff from the user than a simple link and can do different things. automatically removes any script tags, click events and basically any Javascript I assume that means that it also removes javascript:... links. So the only links an attacker can produce are simple GET requests, which amongst others, are ...


7

Yes, it is. By how much, and if it would be ok for you to allow forms depends on your specific situation. CSRF with referer checks If your CSRF protection depends on referer checks, not on a token, allowing forms means that you would be vulnerable to CSRF. As you disallow scripts, a victim would still need to actually click the form, but that can be ...


2

Yes, and quite easily (if I understand the question correctly). If a website has a comments section which allows the user to post anything (or any section where it allows a user/visitor to post anything) and it outputs what they enter exactly as it appears without any sanitation, they could enter something like: <script ...


0

Traditionally the web administration service for most routers is bound to the LAN facing interface with at least basic HTTP auth. So the is strange for Motorola. So they must have either too small a memory footprint so they went with a HTTP server that does not do auth or they went with a language that has a HTTP web server module without HTTP auth built in ...


2

functions such as reboot and factory reset ... why would a modern browser allow internal resources to be loaded from an external page Most of today's routers and other networked devices will be administrated through a web interface. This means that there is some web server with a web application running on the device and the user is using the browser to ...


1

If you know for sure that no user will ever be logged in, you can't really do that much with a reflected XSS vulnerability (you can't steal cookies, you can't post requests on their behalf, you can't perform phishing attacks, etc). I would still consider this a possibility to deface their website though. Sure, it's reflected, but if you post a specific link ...


5

I doubt that this has anything to do with google. According to your description google maps was only your starting point and from there you've opened the different websites for the various business. Some of these sites might be either infected or they contained ads and through these direct infections or the malvertising you got served some Scareware which ...


2

Shouldn't it be possible to use referrer checks as CSRF protection which work even if an XSS vulnerability exists? Nope. If you are injected script, you can create a <form> pointing at the same origin, include a purloined CSRF token, and submit it with the expected Referer header. (Also referrer checks are problematic in general of course, and ...


3

No, I don't think so. It could be circumvented by creating an iframe with display: none, containing the page add-users.php. Then all the attacker has to do is to fill in the form fields and submit the form with JavaScript, and the attacker has successfully added a user without the victim's consent or knowledge. Checking the referer header would not stop ...


1

I've read that JWT tokens shouldn't be stored in localStroage because XSS attacks can read them. True. If you store information in your JWT and don't want an attacker to read it via XSS, storing them in a httpOnly cookie is a good idea. The proposed solution is to store JWT tokens in HTTPOnly cookies and use CSRF w/ double-submit cookies. I ...


0

I never expect a user to use javascript as a search term And users probably won't (depending on what kind of website you have). But attackers will. And they will try to get victims to search for harmful JavaScript (eg by sending them a link), which is then executed in the context of the victims browser. This means that the attacker can now read any ...


1

The goal of an XSS attack is for an attacker to somehow inject code into a webpage that is served from your site. This code is privileged in the sense that, as it was served by your site, the same origin policy lets it have full access to your site's cookies and the contents of the web page that you served. So, if your site responds to a request such as ...


1

Just imagine the following scenario: The user is logged into your site, i.e. has a session cookie. The user visits a link to your site which is controlled by the hacker. Such a link could be embedded into a site controlled by the attacker as <img src=http://your-site/.... Or it could be inside a mail, inside an advertisement (see malvertising) or ...


1

Don't pass user input to the jQuery or $ function if you don't want it to possibly be interpreted as HTML. Use $.find(a) instead, and then you don't have to worry about filtering it. Though you should do this in a try-catch block because the user could give an invalid selector. Also, it's good practice to avoid re-using variables like a for different ...


0

If your looking to completely eliminate chances of being vulnerable to XSS attacks, add this to your PHP script. When you grab the user input and insert into a variable, like this: $input = $_POST['input'];, instead of that (which is 100% vulnerable) go: $input = htmlspecialchars($_POST['input']);. Or, you can also go: htmlentities($input = ...


3

As far as I know it is impossible to insert a completely fake Referer header within a normal browsing session. But there are various ways to make sure that no Referer header is sent at all. Thus as long as you only allow to be framed if the Referer header is set and that the domain in the Referer is explicitly allowed to frame your site you should be safe. ...


1

Wordpress is attacked 3.5 times more often than non-CMSes. WPScan is a great tool that's been around since the BackTrack Linux days. However, there are more tools and techniques available. Here is a list of some newer tools: https://github.com/RamadhanAmizudin/Wordpress-scanner https://github.com/enddo/wp-plugin-scanner ...


1

IMHO, your key problem is that you are not validating the content being uploaded. Since we are only talking about JSON and CSV here, its trivial to write code to validate these. It won't catch all the issues, but it will get most of them. And at least you can tell the uploading user they've made a mistake at the time they are uploading - rather than telling ...


0

The browser IE uses its own security feature to prevent the XSS. The XSS Filter, a feature new to Internet Explorer 8, detects JavaScript in URL and HTTP POST requests. If JavaScript is detected, the XSS Filter searches evidence of reflection, information that would be returned to the attacking Web site if the attacking request were submitted unchanged. If ...


0

Intercept the request using a browser and send that request to the comparer. Then take your original Burp repeater request and send it to the comparer. Compare the two. If nothing is different, then you must have something set that updates requests. I know there are options to automatically update content-length and things like that.


1

A lot of the comments above are irrelevant. None of that stuff really matters. In the app, did the developer create a feature where external links are automatically redirected to the app? If not, the threat is very low. Somebody would have to decompile the app and add that feature in and redistribute it order to successfully exploit that vulnerability. I ...


0

You can try a lot of things it depends what the server is doing. Double encoding, Hex encoding. If I was looking at this my first though would be how can I do it without a backslash. The title tag doesn't need to be closed, you just need to be able to get in to javascript context. In other words you would be abled to insert script alert(xss) /script ...


1

As I understand your question, the actual problem is: Users can upload arbitrary bytes and then trick my help desk people into opening that data as a file in Excel. What if, for example the bytes contain not a csv but a excel file with a macro virus? What can I do? Well. You could have excel not installed on their workstations restrict ...


1

I am going to assume that your support workers will download these files using a web browser. If you are going to display the file inline in the browser: You should disable content sniffing. A malicious user could try to upload a script with a fake content type, and some browsers try to "sniff" the actual content type and run it. Set the ...


2

Your analysis is incorrect. Not all browsers do that, as some googling spits out an excessive blog post that seems relevant. The blog post is old and IE is old, but this should be enough proof that not all browsers encode this, as you expect. So: it is a real vulnerability, it poses a thread to your users.


-1

You're confusing what XSS is, and what it does, I suggest reading the following. The XSS is being executed on the viewer's system, not the server. The goal is to leverage your server to disaffect whoever visits it. Let's explain with an example: An attacker injects malicious code to exploit say IE8. When someone visits your server, or a forum, or gets ...



Top 50 recent answers are included