Stack Exchange Network

Stack Exchange network consists of 175 Q&A communities including Stack Overflow, the largest, most trusted online community for developers to learn, share their knowledge, and build their careers.

Visit Stack Exchange

Hot answers tagged

56

Plaintext injection is an issue. Say you have a page template that looks like this: Hi <name>, Blah blah blah. And you can inject from the URL. An attacker can construct an email with a link to www.example.com/ajax/ads.asp?name=Foo%2C+you+have+the+wrong+version+Flash+plugin%2C+our+company+policy+requires+that+you+use+version+vul.ne.rabl.e.%0D%0A%...


44

Cross site scripting is not a threat to the integrity of your web server. Rather, the problem is that an attacker can craft a site.com URL that will execute arbitrary JavaScript. If your users trust your site and allow it to do whatever it wants, this could be a major security hole.


23

JSONP is a bit dodgy, from a security perspective: Requires excessive trust. Suppose you have a page hosted on a.com and it uses JSONP to access services provided by b.org. This involves placing 100% trust in b.org. If b.org is malicious or buggy, it can subvert the security of the embedding page and all of the a.com origin. This kind of excess trust is ...


23

Imagine if the injected text was: "></script><script>alert("hi");" which would make it look like this: <script src="http://www.site.com/ajax/ads.asp?callback="></script><script>alert("hi");""></script> Then, you have a working custom script that can do anything it wants in the page.


18

Your premise is wrong. Script tags and JSON don't bypass the same-origin policy. The same-origin policy says that evil.com should not be able to read the responses for arbitrary resources on victim.com. Note that Javascript from evil.com can trigger nearly arbitrary requests to be sent to victim.com (e.g., by creating an IFRAME pointing to http://victim....


17

As well as via a cross-domain AJAX request with credentials, the POST in your example could also be sent by using a standard form without AJAX: <form method="post" action="http://MyApp/Page" name="hiddenFormInIframe"> <input type="hidden" name="my" value="a" /> </form> <script type="text/javascript"> document.hiddenFormInIframe....


17

Let us start by defining the term origin. Origin of a page is decided by three unique factors: hostname, protocol and port number. For example, http://test.com and https://test.com have different origins as the protocol is different. Similarly http://one.test.com and http://two.test.com have different origins as the hostnames are different. The origin ...


16

The request can still be sent, just not read: Cross-origin writes are typically allowed. Examples are links, redirects and form sumissions [sic]. Cross-origin reads are typically not allowed. So only the reading of the response is protected by the Same Origin Policy, not the making of the request itself, although only certain headers can be used ...


14

Yes it is vulnerable, but not it the way you suspect. The attacker would not try modify the loaded URL, but to execute the code directly. For example: $_GET['fname'] = '"+(function(){/*any_code_i_like*/})()+"'; will become: $.ajax({ url: "http://mywebsite/script?param="+(function(){/*any_code_i_like*/})()+"" and the code will execute even before ...


12

The callback parameter may be an XSS vector I found an answer on stackoverflow that filters the JSONP callback response. This is needed because the callback parameter can be manipulated into a XSS attack that steals CSRF tokens like this: http://yoursite.com/jsonp.php?callback=(function(){ $(document.body).append('<script type="text/javascript" src="...


11

To prevent CSRF you need to have something unguessable in the explicit part of the request (GET or POST). Putting it into the POST part is preferred, since it's harder to leak it, and you typically only protect requests that trigger an action, which should be POST. A per-session random value is unguessable and should do the job. The standard anti CSRF token ...


11

The PUT HTTP verb is supposed to be idempotent, a smart word meaning that sending twice the request should not have any further effect. The idea is that a "PUT" command is the opposite of "GET": the data contents sent with a "PUT" are supposed to be stored at the specified URL, and may conceptually be obtained back from that same URL with a "GET". In that ...


10

The actual rules of which files a local html file may access are browser depended. Chrome is a lot stricter than other browsers. Firefox allows access to files in the same folder and down the folder hierarchy as far as I remember. Ordinary people with little in-depth background knowledge may save a html file with a cooking recipe, a book extract, a travel ...


9

No, it is not secure and using another domain will not help. An attacker can manipulate the html/javascript code on the http-page to change the destination of the ajax call to his own server. Or even better, add a second call.


8

No you are not vulnerable in that scenario. The reason is exactly as you explain - a third-party site could generate a request to your site, but the authentication details will not be attached.


8

So there are a few reasons why you don't want to do this, although I do not understand the code you presented as I do not deal with that. You should use a third party library to manage your sessions. There are several reasons... Code is vetted, tested and improved across a much wider audience when you use a built in or well know authentication scheme. When ...


7

From the outside, one can only see the length of the exchanged data, i.e. the total length of the request, and the total length of the response (rounded to a multiple of the symmetric cipher block size, e.g. 16 bytes if AES is used; but not rounded at all with RC4). To avoid leaking any information, all requests and all responses should have exactly the same ...


7

The purpose of the same-origin policy is to protect the user (client) and not you (the server). Thus, it's irrelevant in this case. Attackers can use tools like wget, cURL, and even simply inject custom JavaScript in modern browsers using readily-available tools such as Developer Tools. Therefore, it doesn't matter if old browsers have certain behaviours or ...


7

Yes, you can use a custom header such as X-Requested-With to protect AJAX requests from CSRF. A customer header is not allowed cross-domain without CORS being enabled on your server. The Origin header could also be used, however the logic for this is not straightforward. If you wanted to add extra security to the custom header in the spirit of defence in ...


7

They are both equally secure. There are mistakes you could make in any version, but none is inherently better than the other. What is relevant for the security of your login is the server side. You can put no security restrictions on the client, since any such restrictions could be trivially bypassed. So the important thing here is the code on the server ...


6

OAuth is flexible, and sometimes the OAuth flow is modified for application specific needs. The most common two flows are 2-legged and 3-legged, which if these flows are implemented correctly, then they are generally accepted as secure. The proposed CORS AJAX implementation of the OAuth flow violates two security requirements of RFC-6749 - OAuth 2.0 ...


6

The same-origin policy is a client-enforced restriction. Certainly, it's possible for a particular client to fail to enforce this restriction. Note that doing so would bring the client out of compliance with W3C standards for the XMLHttpRequest API and iframe behavior. Note that any program that can formulate an HTTP request can send a request to your site. ...


6

From what I understand using GET to submit usernames/passwords is a security issue because the username/password are part of the URL which can show up in browser history. That's not the only issue. Using GET for situations where the user is submitting data opens up your application to CSRF vulnerabilities. For example, I could embed <img src="http://...


6

If you want the user to issue the request, then it is not possible to do this with an XMLHttpRequest: Terminate these steps if header is a case-insensitive match for one of the following headers: Accept-Charset Accept-Encoding Access-Control-Request-Headers Access-Control-Request-Method Connection Content-Length ...


6

You should use POST for any state-changing action. If you save the content of the form, or use the form to send an e-mail, you should use a POST. There are several reasons why this is more secure: CSRF is easier with GET requests than with POST requests. With GET requests you can simply send someone a link. With a POST request an attacker needs to have a ...


5

The callback parameter may be a CSRF vector via Flash injection. See http://quaxio.com/jsonp_handcrafted_flash_files/


5

Yes, you could do this. This should be fine. It is a reasonable defense against CSRF. Do make sure that side-effecting actions can only happen via POSTs (never via GET), and that all POSTs check for the presence of the token. Also, make sure you generate the token as a cryptographically-strong pseudorandom number (e.g., using CryptGenRandom(), /dev/...


5

Once your browser visits the domain www.example.com and downloads index.html to your browser the entire html is stored on your computer. Since anything stored on the client side can be tampered with this is considered unsafe and you can not trust the data the client is returning from the script supposedly www.example.com served to the user. This means that ...


5

Since you'll be making calls to the API server via Ajax (meaning the same page - and the same JavaScript context - will be constant) I'd suggest creating a short lived token in the main server, having the browser request it once, then using it to authenticate with the API server until the page is closed (or the token expires, whichever happens first). Next ...


5

If it is a secure CAPTCHA, the AJAX message will send the user's input to a server. The server will validate the input and return a token. The token will then be inserted into the form by the Javascript. When the form is submitted, the server will validate the token with the CAPTCHA service (this could be a web service call or signature validation). So the ...


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