JSONP在CORS体系中的定位及相关安全问题与CSRF Token咨询

Hey there! Let's break down your questions one by one—since you're new to cross-origin security, I'll keep things practical and avoid overly jargon-heavy explanations.

Absolutely. JSONP works by exploiting the fact that <script> tags aren't bound by the same-origin policy: you load a remote script that wraps JSON data in a callback function you specify, which gets executed in your page's context. This execution is exactly where the risk lies.

For example:

• If a JSONP endpoint doesn't validate the callback parameter, an attacker could craft a malicious callback like alert(document.cookie) and trick a victim into loading that endpoint (via a malicious link or embedded script). When the script runs, it would steal the victim's cookies or execute other malicious code (a form of XSS).
• If the JSON data returned includes user-controlled content, an attacker could inject malicious code into that data, which would also execute when the callback runs.

If you have to use JSONP (instead of switching to CORS), here are key safeguards:

• Strictly validate callback names: Only allow alphanumeric characters and underscores. Use a regex like ^[a-zA-Z0-9_]+$ to reject any callback with special characters or suspicious keywords (like alert or eval).
• Restrict request origins: Check the Referer header to only allow requests from trusted domains. Note that Referer can be spoofed or omitted in some cases, so don't rely on this alone.
• Never return sensitive data: JSONP responses are executed in the client's context, so never include session tokens, passwords, or other sensitive info—attacks could easily siphon this data.
• Replace with CORS where possible: CORS is a modern, standardized solution with far better security controls. Use it instead of JSONP if your target browsers support it (which almost all modern ones do).

First, let's recap CSRF: Cross-Site Request Forgery is an attack where an attacker tricks a logged-in user into performing an unintended action (like transferring funds or changing a password) on a trusted site.

A CSRF Token is a primary defense against this:

• The server generates a unique, random token for each user session and stores it (usually in the user's session cookie or server-side session store).
• When the user loads a page that triggers a state-changing action (like a form submit), the token is embedded in the page (e.g., a hidden form field or a custom request header).
• When the user submits the request, the token must be included. The server checks that the token in the request matches the one stored for the user's session—if not, the request is rejected.
• Since attackers can't access the token (thanks to the same-origin policy), they can't craft a valid request that includes it.

Think of JSONP as the "old school" workaround for cross-origin requests, invented before CORS existed.

• Before CORS: Browsers strictly enforced the same-origin policy, so you couldn't make XMLHttpRequest (XHR) or fetch requests to other domains. Developers turned to JSONP because <script> tags bypass this policy—loading a script from another domain is allowed, and wrapping the data in a callback lets you use it in your code.
• CORS as the modern standard: CORS is a W3C-defined protocol that lets servers explicitly allow cross-origin requests. It supports all HTTP methods (not just GET, like JSONP), allows custom headers, and has built-in security controls (like preflight requests for complex requests, and credential management).
• Current role: JSONP is mostly a legacy solution now. It's only really used if you need to support extremely old browsers that don't handle CORS. In all modern scenarios, CORS is the safer, more flexible choice.

内容的提问来源于stack exchange，提问作者Kle