Tag Info

Hot answers tagged

17

The "better way" is server-side validation, because you simply cannot control what the client will send. It does not matter what client-side method you use - <input maxlength=, javascript, what-have-you. To quote OWASP: Note that client side validation is a fine idea for performance and usability, but it has no security benefit whatsoever. Server ...


6

Not a signature, however a Content Security Policy allows you to whitelist JavaScript for execution in your page by including a SHA-256, SHA-384 or SHA-512 hash. e.g. to allow <script>alert('Hello, world.');</script> you would include the following HTTP response header: Content-Security-Policy: script-src ...


5

It's in the page source, nested in an HTML table cell as: <td width="194" height="34" class="poll_row_border" style="padding-left:4px;"><div align="right" class="tool_description"> "><ScRipT>alert(31337)</ScrIpT> </div></td> Interestingly, there are two sets of similar code that ...


4

According to your question Chrome was loading a plain HTTP favicon in a HTTPS page without any browser warning. Interesting. Redirecting to a plain HTTP website is not a vulnerability in itself. However, it is a security flaw if the redirect is accidental and you want your users to remain on a secure, trusted channel to your site. Script content will not ...


4

Nope. That's pretty much the best you can do on the client. The key is to have strong input validation on the server. Always treat all input as suspicious. Input validation on the client is to improve the user experience. The security happens on the server. PS: You could add JavaScript validation but it adds no real security because an attacker can bypass ...


3

There are two main types of issues that can occur with client-side execution: A malicious client can modify their client state and attempt to make the server accept that modified state as valid An unsuspecting user can be tricked into running code in their console by a malicious third-party, something caused Self XSS Malicious clients running ...


3

Yes it can be an issue but there are ways for applications to protect against it. Two sides to every internet application. In order to understand internet application security you have to understand the difference between the client and the server. Data which is generated by the client (the browser), must be sanitized and validated before being by the ...


2

There is no XSS in the pasted code. This is only setting the hash of the URL e.g. https://example.com/foo/1#var/1 using the location object. XSS can only occur when something in an HTML document is set without proper encoding. Note that this answer is based on the posted code only, and no assumptions are made about where the hash is later used. If the use ...


2

A snippit of javascript is a string, so it can be passed to a crypto library to get signed just like any other string. Try googling "javascript crypto library" and see if you like any of the libraries that come up. Any crypto library will have signature functionality.


1

While the question is specifically about AngularJS the issue lies in the fact that anything that is completely controlled and executed on the client side cannot be trusted. For anything that is accepted from the client side MUST be validate on the server before use. That is the only way to feel relatively confident about the operation. Modifying the ...


1

Finally busting the NoScript Scam. Or as it were. It's long been time your question was raised on the 'net. To start off getting into answers, let's just take one of these surrogates allegedly meant to keep sites working the way "you" want and see what it does. I'm picking one at random - "noscript.surrogate.adriver.sources" (of course, that's "Ad River", ...


1

Yes, it can be bypassed. First, many filters that attempt to remove <script> tags do so in a way that is easily defeated. For example, they may improperly handle input like <scr<script>ipt>. But even when implemented "properly", that is not sufficient, because <script> tags are not required to execute Javascript on a page: event ...


1

There is indeed a vulnerability, because as you observed, an attacker could intercept the traffic on the unsecured line and change it. The reason your script didn't execute is that this came in the favicon, and Chrome (apparently) does not execute scripts in the favicon. To exploit this, you would have to get Chrome to execute the code in the favicion. ...



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