Hot answers tagged

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

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


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


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


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


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


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.


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


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


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

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

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


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


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


2

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


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


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


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



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