Tag Info

New answers tagged

0

for as long as i know, aslong as your PHP scripts (i.e. forms) use the filter for htmlspecialchars() and strip things like weird symbols and backslashes, there wouldnt be a security risk, atleast from my perspective. forcing a charset to be used by the clien is an option for us paranoid people though, along with the basic stuff i just named.


1

My question is- why don't we store what ever is going to server as parameters and if these parameters are reflected in HTML response then discard it or encoded it Any parameters? So if I search for “Hello” and the response page contains the text “Here are your results for Hello”, it gets mangled? There has to be some criterion for what counts as ...


1

this approach is already found in various frameworks and works (more or less) against basic attack-patterns. another, more elegant way is to use CSP, but you have some requirements when using this approach (no inline js/styles etc) the problem is, from defender-pov, an attacker might have other points), nasty stuff like encoding, nullbytes and different ...


0

An attacker could use social engineering to trick the user into entering heavily-obfuscated javascript into that box. The attacker could claim that by entering that code something really funny or awesome will happen, but what actually happens is that it compromises their login credentials.


2

It will render that content in the div and show the alert. My question is if the act of rendering the contents of the textbox on the client side could pose any kind of threat? If so, what could a malicious user do? If this is the case I would fix it (defence in depth), but as AviD pointed out without seeing the full site and its context, it is ...


0

It is DOM-based XSS, so it is a security threat. Even it is self-XSS, it can be used in social engineering attacks, so you must fix it. Also you can use http-only cookies and some additional http headers for protection


1

The request and response the reports show are not so much for detecting (since it already detected it) its more for solving it. By looking at the request you can see in what URI and what parameter the tool injected the script and by looking at the response, you can see where the injected script was reflected. With this information, you can now go to your ...


1

Sanitize your input, by escaping HTML special characters. In PHP this is done with htmlspecialcharacters. Make sure you do not supply a flag that prevents htmlspecialcharacters from escaping the type of quote you use. Your problem is your URL is http://example.com/?s=login&m=forgotten" onload=alert(966) bad=", which your PHP code which is probably ...


0

By prevent, do you mean a code fix, IDP rule, something else? Assuming code fix, then what language is it written in, what framework, etc? In general, what you'd need to do in the code is everywhere where data (especially coming from user input) is written back out, that the data is properly escaped in its context (be it HTML, URL, JavaScript, etc) of ...


0

Disclaimer: I'm the gem author. I wrote Codesake::Dawn, a security source code scanner for ruby code. I'm close to release version 1.1.0 with 171 security checks (CVE bulletins and Owasp ROR cheatsheet) included. It works with Sinatra, Padrino and Rails web application out of the box. It doesn't detect xss introduced in your code... yet :-)


0

Zend Framework offers an Escaper component to escape output and defend from XSS Symfony provides an automatic output escaping feature CakePHP before version 2.4 provided a sanitization class I recommend you the following lectures for further information: Secure Application Development with Zend framework


0

IIRC Wpscan just tests for the presence of the plugin not that it is a version which is specifically vulnerable, so what you're seeing would be consistent with the site having the plugin installed but a non-vulnerable version. Beyond using tools like wpscan you could just use standard black-box web app testing tools, like arachni and then move on to manual ...


4

BeEF has 4 ways to keep user browser hooked - Create popup under the browser to keep BeEF js code executing, Prevent closing tab with BeEF code running by asking confirmation Open new pages in foreground iframes Capture all link clicks and load new pages through ajax, without reloading page. Details are here: BeEF Persistence


6

I work at Disqus and I feel the answers above are misinformed about how our application works. Basically, our application is loaded almost entirely inside an iframe. This dramatically changes how your site is exposed to both our code and 3rd-party code. Am I essentially giving scorecardresearch.com access to my users and user's cookies for my domain, ...


4

OWASP's XSS Filter Evasion Cheat Sheet clearly states that the cases you mention are for old browsers Deprecated Tests (Works on IE 6 and older browsers) These are the tests that have only been confirmed to work on IE 6 unless specified otherwise and do not work on any modern browsers as of March 12th, 2014. Remember, though, not all of your ...



Top 50 recent answers are included