New answers tagged

3

This code snippet is vulnerable to XSS in jQuery prior to 1.9. Even now, it remains at least a bad practice. The string argument to $() (shortcut for jQuery()) can be parsed either as a CSS selector or HTML code. Parsing the string as HTML implies an XSS vulnerability, just as document.write() would. On the other hand, injecting into a CSS selector is not ...


1

This was a pretty common XSS attack vector in jQuery, and can still affect sites using an outdated version of jQuery. https://bugs.jquery.com/ticket/9521 Basically, if a string was an invalid selector, jQuery would assume it was HTML, and parse it as HTML. In jQuery version 1.9 jQuery mitigated this risk by only parsing a string as HTML if it started with ...


2

That link is reasonable. Why do you need to manually test for vulnerabilities? Because a tool it's just a tool someone else created and he might have forgot to add a possible payload. Don't know about any specific case though, although I'm not much on the "offensive" side nowadays. So, if you are the developer, a good approach is to: Know where are you ...


2

Automated tools are only as good as the people who made them (i.e. the test logic they contain and the rules/signatures they use). "Garbage In Garbage Out" as the old saying goes ! In pretty much all automated security testing tools I've used there have always been false positives and false negatives. Therefore in order to ensure your test results are ...


5

The relevant code for the HTML generation is the following: for (var i=0; i<posts.length; i++) { var html = '<table class="message"> <tr> <td valign=top> ' + '<img src="/static/level2_icon.png"> </td> <td valign=top ' + ' class="message-container"> <div class="shim"></div>'; html += ...


0

Yes, your SVG can easily be altered to execute arbitrary code. You have a reflected XSS vulnerability right there. When you have <svg width="<?php echo $_GET["name"];?>" height="100"> <circle cx="50" cy="50" r="40" stroke="green" stroke-width="4" fill="yellow" /> </svg> Set name be equal to 40"> <script> ...


0

White-listing the characters is always the best practice instead of black-listing special characters. I had seen the same thing with one of the apps I was assessing. So, I found an input parameter which showed in response at three different places. One of which was inside " " in a-tags. No wonder, XSS was easy there. And yes, already mentioned, many of the ...


4

Your sql statement: select * from foo where numerical_id=$foo; The POST request foo=1;drop%20table%20foobar; The resulting value in $foo foo=1;drop table foobar; The resulting SQL statement select * from foo where numerical_id=foo=1;drop table foobar; Can it also be valid to prevent SQLIs? Obviously no. As for the XSS: Your PHP: ...


1

First and foremost XSS is entirely dependent on context in which the output is displayed. Forcing all input though the same filter will never work all of the time - and will require the developers and penetration testers to hunt for all of the injections. The content security policy will help prevent all types of XSS, even when the application suffers from ...


4

No, in a HTML context you cannot inject new tags without allowing letters after the opening bracket. Still, this filtering technique is unnecessarily risky. The HTML parser of your web browser parses code as a state machine. To understand what your options are, have a look at the HTML syntax specification and the possible state transitions. Your injection ...


1

In this particular case, you are injecting your input as HTML code (since it is between the span tags and content type is text/html). So, the only way I can think of for injection JavaScript code here is using HTML tags. Given how the server is responding back, it is very unlikely you can inject JavaScript in this particular case. You have 2 options: First, ...


2

No, including the cookie name or username in the page is not an issue. The session/cookie name is not secret information, everybody can see it. [Including the content of the cookie on the other hand would be a minor problem, as session cookies are generally supposed to be httpOnly to mitigate some of the risks of XSS]. The users email address also should ...


0

1. Change the link As suggested by AadvarkSoup in comments, an attacker can change the href attribute of the link on page A, so instead of page B it goes to http://evil-pishin-site.com/login. Most users would probably not notice the change of domain, as they don't expect it to change. 2. Simulate page B As Xavier59 suggests in his answer - when the user ...


3

Very unlikely. The only vector I can see is a character encoding bug whereby the backend language (e.g. PHP) is configured to use a different character encoding than UTF-8, and it isn't encoding-aware when outputting the string. That said, I'd say it's almost certainly not possible to get XSS in this instance. You could, however, get XSS in any location ...


-4

You should be able to just use the space like you've shown is allowed: < img src=x onerror="alert('xss')">


4

The attacker could add some onclick event attribute on the different link of the page. When the user click on a link, he'll think he got a simple disconnection bug, instead of that, you're onclick event loaded a fake connection page. But, you're still on the domain and you can even manipulate the url with history.pushState(); as an example.


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.


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


0

If the sole concern is "hook.js" browsers such as Mozilla, Firefox have script blockers addons (e.g. noscript), if you're using IE, you could enable script blocking which would render any javascripts moot. As for tracking the communications server, you could use netstat: netstat -an | findstr 8080 That would only work if whomever set a port to 8080. Your ...


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


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


-3

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


5

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



Top 50 recent answers are included