Hot answers tagged

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 ...


6

No. PHP will parse the php file looking for either <?php, <? or <?= (depending on the value of short_tags) However, outputting <?php to the screen would not execute code. It would need to have been evaluated (eg. saved to a .php file in the server that you then run). This form is probably vulnerable to XSS, though.


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 ...


5

<iMg SrC=x OnErRoR=window.location=123> The mixed case parts in your example are not the Javascript but the HTML. And HTML is case insensitive <iMg HTML img tag (i.e. image), case insensitive SrC src attribute for HTML img tag, case insensitive OnErRoR onerror attribute for HTML img tag, case insensitive window.location=123 - ...


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 ...


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 ...


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 ...


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. ...


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 ...


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 ...


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 ...


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 ...


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 ...


2

There are Yara rules submitted by SANS ISC to detect BeEF, and these could be repurposed by yarashop for the network layer as a early-warning detection system. The author shows how to utilize Volatility to read into a memory capture and look for BeEF-related signatures and communications -- ...


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 ...


2

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? CSRF? Same-site cookies can ...


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 ...


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 ...


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 ...


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

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 ...


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 ...


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 ...



Only top voted, non community-wiki answers of a minimum length are eligible