Tag Info

New answers tagged

0

I use the OWASP PHP Filters. They're really simple to use and effective. https://www.owasp.org/index.php/OWASP_PHP_Filters The source code is highly readable. There are a lot of painful lessons in there.


3

XSF is, essentially, XSS in a Flash applet. Where in XSS you find vectors (e.g. URL parameters or form fields) for injecting content into the DOM that is parsed as script, in XSF you look for cases where you can get untrusted data to be placed into Flash variables, which may then be used in an unescaped context inside the Flash applet, resulting in script ...


0

Definition taken from OWASP DOM Based XSS (or as it is called in some texts, “type-0 XSS”) is an XSS attack wherein the attack payload is executed as a result of modifying the DOM “environment” in the victim’s browser used by the original client side script, so that the client side code runs in an “unexpected” manner. That is, the page itself (the HTTP ...


1

How are you generating the record ids? If they are incremental, I could retrieve all of your images in a breeze… (but as I don't know what are those images for, perhaps you don't care 😉)


1

So at first moment i thought an alert('xxx') is enough to create a POC but inserting alert or any thing else is leading the code to become faulty Breaking the code is usually a good sign. A syntax error may show the victim is not performing the correct escapes to keep the code valid. Look at the generated source to see what it produces for your input. ...


0

XSS attacks are based upon the fact that input becomes output to the end-user's browser. The most common attack is basically a PHP site containing <?php echo $_GET["message"]; ?> You would then pass this URL a parameter containing the javascript code. If you want to set this up, create a something.php file on your web server, input the above code ...


1

In addition to the informative answer of Philipp. Key Loggers are highly appreciated by attackers, this is the gold to watch for. Many advances have been made, up to replacing a keyboard with a 'tapped' keyboard or even have a 'tapped' mouse put in place. More advanced are almost 'invisible' devices which proxy the data using bluetooth. The frustrating ...


6

Keyloggers are usually programs which run in background on the users operating system. There are lots of ways to install these on the users machine. Some examples are: The attacker learns about a vulnerability in the victims web browser which allows to download and install arbitrary programs from the web, and then tricks them into visiting a website they ...


2

Apart from it being an inefficient way to store an image, storing the image in a database isn't any riskier than storing it on the filesystem. The major difference between the two is that filesystem storage is vulnerable to directory-traversal attacks, where database storage is vulnerable to SQL injection attacks.


3

$("div[id="+t+"]") That's not JavaScript injection. For it to be JS injection, the attacker-supplied value would have to be written into the JavaScript code from the outside (for example in a server-side templating language or eval in JS itself). That's not happening here, there is no dynamically-generated JavaScript. There's just a plain string ...


1

The string t is not being eval'd, it is a literal string. String concatenation just creates a new string, you have a similar situation to a simple var y = 'Hash: ' + location.hash.slice(1); which doesn't open an XSS vector. It just assigns the hash to a variable in Javascript. The result works the same as: ...


1

I'd be tempted to put a proxy between the server and the client and compare the output of the request byte for byte. That should rule out server differences due to browser headers in the request etc. and will narrow it down to local differences. You could then also capture the output in the proxy and load it into each of the browsers on each machine (as a ...


2

What is addslashes for? It has no benefit against HTML injection as it does not remove the characters that are special to HTML. If it is meant as a protection against SQL injection it is ineffective, especially for non-MySQL databases that don't even use backslash as an escape in SQL string literals. You should exclusively use parameterised queries to get ...


1

The attack described in mustache-security describes a bypass of a Web Application Firewall (WAF) that try to prevent XSS by dropping HTTP requests that contain <script> tags. If a page is using KnockoutJS, then an attacker can use a <div> instead of a <script> tag to obtain code execution: http://localhost/xss?id=<div data-bind="html: ...


0

The following code is vulnerable to DOM based XSS, because the attacker-controlled value of document.referrer is tracked by the browser: <script src="' + document.referrer + '"></script> The code above can be exploited using a page that upon first load redirects the browser to your target, on the 2nd load it returns an XSS payload. One way ...


0

The problem with reflected XSS is much the same as Stored/Persistent XSS except it requires a social engineering element. By emailing an (otherwise) legitimate link to users, anyone who clicks on the link with be susceptible to the XSS. Or, of course, you can host it on a web page, and wait for somebody to click a link, or forward their browser to it. But ...


0

If you use CORS for anything else then XMLHTTPRequest (which historically defaulted to only allow same origin) it has to be supported on the client side (browser) and it also has to explicitly used on the server side. By default cross origin requests can be done simply be including an image, stylesheet, script etc from another site and if you have a ...


1

Refering innerHTML of generated HTMLElement causes mXSS - a kind of DOM based XSS. e.g, the code following causes mXSS at IE. var s = "<listing>&lt;img src=1 onerror=alert(1)&gt;</listing>"; var parser = new DOMParser(); var doc = parser.parseFromString( s, "text/html" ); div.innerHTML = doc.body.innerHTML; therefore, you have to ...


1

&lt; and &gt; are the correct ways to display the characters < and > in an HTML context. (There are places where just escaping <>&" isn't enough—for example unquoted attribute values, or JavaScript nested inside HTML. Do you have that?) You would usually use the term “bypass” when you know/suspect there is a vulnerability, but ...


2

Someone could pass a link to //xss.com/malware.php, by encoding it as https://www.example.com/login.php?previous_page=%2F%2Fxss.com%2Fmalware.php. To prevent this, you could pass the path from the site root as the parameter, so you would pass only dashboard.php. Then assemble the full link on the server side.


1

From MDN: encodeURIComponent escapes all characters except the following: alphabetic, decimal digits, - _ . ! ~ * ' ( ) You would normally require a space character to add another attribute (such as onclick), unfortunately this will be encoded as part of the URI. However, from OWASP XSS (Cross Site Scripting) Prevention Cheat Sheet: Unquoted ...


1

Error pages can have reflected XSS vulnerabilities too, especially when any error trace includes input parameters. If a vulnerable error page is served when the CSRF token is not present, then your CSRF protection does not prevent reflected XSS.


9

The answer is usually yes if the value is only reflected if a valid CSRF token is provided - the user can only "attack" themselves in this instance. However, if there is a form generated that correctly encodes output to a page that contains a CSRF token but then that form submits to a page that does not correctly encode output then your site is still ...


1

I would demonstrate a simple SQL injection, it's always nice to see the look on people's faces when you attack a website with a browser as your only weapon. Setup a simple site with a login page and then show them how you can expose the admins password by simply adding few characters to the url. After you get the admin's password delete the entire site. ...


0

The most important Things in this case is security. We want to give some HTML text from user or maybe by ourselves, then store it for exam in DB, then get it and show in webpages without fearing from any type of attack and misused by users with bad intention. I'v been researched about the best way to do that about 4 days and found 2 base ways. Please let me ...


1

Appscan has the "show in browser" feature that opens Appscans special "worst of all worlds" browser for the given vulnerability. If it isn't a false positive, this browser should execute the Javascript. I have found it a pretty reliable way to check for false positives. For all other testing, I've found that Firefox is the least protected from XSS, so I ...


0

There is the sand cat projet which provide a lot of pen testing tools, like scripting in lua, better view over the console and dynamic injection tools, and a lot of other good surprise.


3

When something like Burp finds an XSS vulnerability, I can't ever verify it when using something like TamperData. If you are already using Burp to find the vulnerability, why not use the intercepting proxy functionality to modify the request and to inject the XSS payload?


5

Your best bet would be mantra from OWASP: http://www.getmantra.com/ Contains a myriad of tools for penetration testing out of the box. Also open source should you need to add/modify anything.


8

Most browsers allow you to disable the function. For instance with chrome you need to start the browser using C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --args --disable-web-security For Firefox you have to go type about:config in the address bar. Then you need to set the browser.urlbar.filter.javascript to False. For Internet Explorer ...



Top 50 recent answers are included