Tag Info

New answers tagged

0

You may want to look into setting your webserver to HSTS (Strict Transport Security) which uses a special response header to tell the browser to only accept https traffic. Full Disclosure: As you might have expected, IE support < 11 I believe is limited. If you must use something client-side to check for https I think you could use ...


0

You might try the following: Create a cookie with Javascript. Set the secure flag on the cookie, so that it is only usable for https connections. Make a https request to the server and check if the secure cookie was received. If it was not received then you can assume that the request on the client side was not done with https, i.e. something like sslstrip ...


0

To some extent it may depend on the design of your web app and the level of security your app requires (based on a risk assessment). In short, there is no one answer suitable for all situations. The key to a good user experience is ensuring your security level is in-line with the actual requirements. Too stringent security requirements with too short a ...


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 ...


0

Javascript, and all other client side technologies, are inherently insecure. You can't keep people from cheating, only make it more difficult.


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 ...


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 ...


0

cant send a victim this link with the injected code This might be possible if you find that some input will populate the field. Try POST and GET requests for the page, and attempt to populate the field using either its name (if it has one), but also try id and other variations. Have a look at the rest of the application and see if there are any ...


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 ...


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", ...


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

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 ...


0

Encoding / Decoding coupled with XSS sanitation pre save and pre dom render is best practice. Mitigation strategies regarding browser DOM XSS attacks vary but can be strengthened with header options found here (https://www.owasp.org/index.php/List_of_useful_HTTP_headers). While zero day vulnerabilities may exist in the various browser rendering engines ...


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 ...


0

Redirection with Javascript or META tags ... You can not send a 301 status code via Javascript or META tags. Since the HTTP status code of the page will remain 200 OK ... ... Another disadvantage is that some browsers disable Javascript or META refresh. Therefore, one must include a link to the destination page in the body of the page ... URL redirection ...


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. ...


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 ...


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 ...


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 ...


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 ...



Top 50 recent answers are included