Tag Info

New answers tagged

1

I'm of the opinion that you should filter (block) xss input AND escape user-supplied input on output. Why? Because databases are long-lived and often shared, so should not contain xss. And web applications often use more than one data source. If you're using Java, you can use Hibernate Validator with JSoup to parse and validate HTML input. It has a ...


1

By definition, the FHIR is asking you to preserve the XSS vulnerability of the data (store as code, display as code). XSS requires that the data be displayed back to users, which could be prevented with output validation, instead. Accept the input, store as JSON, filter when displaying the HTML data as HTML code. Depending on the "output" systems, this could ...


2

1- why there are html code if the browser will redirect it automatically It's traditional from the times where 302 was new and not every client understood what it means. It is not really needed today and uselessly wastes bandwidth. 2- if inject code in href, a javascript code can this executed before the redirection happened ? or not ? If you have ...


-1

If the user is authenticated and an attacker manages to use some kind of exploit to inject javascript (or flash) into the page, then yes, the attacker will be able to steal the secret token. They simply make a request using AJAX to the /auth endpoint and read the redirect URL that comes back. This was made possible recently by the addition of the responseURL ...


2

You can use rate limiting, that's a module for that on Apache, Nginx, and IIS. Rate limiting can hurt people standing behind a proxy (like me), so you should not deny access based on the limit, but to employ another defense as soon as the limit is reached. A captcha based defense is useful, and some captcha systems (like ReCaptcha) can be processed without ...


2

The database part of this is largely irrelevant, as a non-insignificant portion of your load will be on your web server rather than the database. There are four common ways to implement rate limiting: Perform rate checks against the user context, client IP, and other information within the application. This will allow more granular control of what types ...


0

Like you said, Usually user/ip based rate limiting is used to prevent excessive requests. If your application detects a user/ip submitting requests beyond a threshold your application should stop storing the requests in the database to prevent a denial-of-service from occurring.


0

You can checkout for this too ONLOAD=alert('XSS') Which will produce an alert box when the page loads.


18

Try this: " onfocus="alert(1)" autofocus=" It will expand to: <input type="text" id="search-text" name="query" value="" onfocus="alert(1)" autofocus="" /> Which will cause an alert box, demonstrating XSS.


4

Any decent static analysis scanner would not flag up a vulnerability if you were storing raw HTML in your database - after all, it's only a string. String sequences only become dangerous when passed through a "sink function". For example, <script> is completely safe to store in your database. In fact so is Robert'); DROP TABLE Students;--. The ...


1

If you are going to persist those characters, ensure that you used bind variables (or prepared statements) to persist them. You should also then add HTML Encoding when displaying the information on your User Interface.


0

If you can avoid storing such characters for reasons you mentioned (and others), that is the best for you. However if you are forced to regarding your business model you still have an option: Whatever the programming language you are using, you can always rely on the concept of parameterized queries to fulfill that goal. That way you prevent SQL ...


0

As the commentators suggested you correctly, you will need to use the HttpOnly fla as a solution. But I just want to add a note regarding the right comments you received about HttpOnly flag. In fact, if a client of your website uses a Mozilla Firefox browser of version before 3.0.6 (Bug 380418: XMLHttpRequest allows reading HTTPOnly cookies) and/or ...


2

A mature wiki software like Wikimedia usually does not allow normal users to embed any scripts in wiki articles. But still, wikis are prime targets for search engine spammers. The structure of wikis is very search-engine friendly which means that wikis often get quite a lot of page rank which in turn exends to any websites linked from them. Also, anything ...


2

I've never before seen anything like this. Is this the only case or has this been known to happen? The scenario you experienced could be innocuous as highlighted in @RоryMcCune' answer as well as it can be a nefarious attempt/attack. Let me explain this last scenario. There is one interesting scenario about your question: as @RоryMcCune said, what ...


13

Wikipedia and big popular sites are mostly safe, as any security holes are found quickly, usually long before the site gets its momentum. Smaller blogs/forums which allow user content are more vulnerable. I used to visit a Russian tech blog several years ago, and the posting form allowed some HTML formatting. Someone managed to include JavaScript code from ...


44

Assuming that you are coming from a BT connection, it's possible that this is part of the BT parental controls program. There is a discussion of a similar looking pop-up here , which seems to tie into what you're seeing, and also a thread here on the BT site which has a link to a process to turn off that setting. To test this theory you could log into ...



Top 50 recent answers are included