Most of the details in your question are irrelevant. That the ID is stored in a HTML id attribute, the developer tools, that you are using jQuery... None of that really matters.
The only thing that matters is that you have an endpoint on your server called insert.php. An attacker can send any request they want to that endpoint, regardless of what your ...
You must at the very least check for Content-Type: application/json on the request.
It's not possible to get a POSTed <form> to submit a request with Content-Type: application/json. But you can submit a form with a valid JSON structure in the body as enctype="text/plain".
It's not possible to do a cross-origin (CORS) XMLHttpRequest POST with Content-...
The reality is if other processes can access your process memory or features of your
virtual machine, the game is probably over as you're already compromised. If a process
has access at this level, it can probably gain other information, such as the initial
credentials used to authenticate before obtaining the token or just modifying
results to make token ...
JSON Web Tokens (= JWTs) are based on the RFC 7519 and all differences will be extensively described there. If you take a look at this, you will see, that they are much more than what you seem to have in mind.
Among other things, these tokens:
are used to assert claims (for instance "logged in as admin")
are signed with a message authentication code (e.g. ...
CBC and GCM are quite different. Both are secure when used correctly, but CBC isn't as parallelizable and lacks built-in authentication. Due to this, CBC is only really practical for encrypting local files that don't need random access.
As for any advantages it might have, CBC doesn't fail as catastrophically if the IV is reused, and it can be faster if ...
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 ...
The jti claim as described here is an optional mechanism for preventing further replay attacks. From the spec:
4.1.7. "jti" (JWT ID) Claim
The "jti" (JWT ID) claim provides a unique identifier for the JWT.
The identifier value MUST be assigned in a manner that ensures that
there is a negligible probability that the same value will be
A summary of how CSRF attacks work goes like this:
You, the good user, while logged into a web site A, visit some other site's page B.
That page does a GET (can be a POST, a little more complex to set
up) to a page X on site A (which you are logged in to), with e.g.
. Your browser obliges, using your already authenticated session/cookie
Page X by design ...
My immediate reaction to this was not positive, for a few reasons.
Trying to use regex to parse complex language constructs is a bad idea. Regular expressions just aren't suitable for such constructs.
Security through blacklisting is a bad idea because you will always be, by definition, one step behind the attackers. You should use a positive security model....
To answer your questions:
1) How do you handle a situation with a compromised token secret which is shared between a client and the server?
Add an expiry date to your token. Make sure the token cannot be used after the expiry time. But this doesn't prevent unauthorized access within the token's expiry period.
So, to overcome this problem you can embed ...
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:
From my other sec.SE answer:
JWT are self sufficient tokens which are used to share authentication information between different systems. They solve the problem of relying on third parties for validating an authentication token as all the information required to validate the JWT is contained within the token itself. This simplifies the process of on-...
CBC is older, which means more compatibility and just overall historical reasons.
There are performance advantages, if you don't need GCM for authenticity. You often may want your own system for authenticity with some additional characteristics or you may not need it at all.
There have been different proposed countermeasures against unwanted script inclusion, but putting an infinite loop (I have seen for(;;) used in Facebook APIs) or producing a syntax error (some Google APIs use )]}' as in ...
Is this application vulnerable to CSRF attack?
Yes, it's vulnerable. The prerequisite, however, here is Flash. With the help of Flash, it's possible to forge a Content-type header with any arbitrary value. What you need to do is POST a request to your own domain, and then issue a 307 redirect. Please refer to below screenshot:
For more information, please ...
This is often brought up everywhere, partially because everyone keeps repeating the mantra that input sanitation is the answer. It isn't. It's dangerous, bug-prone, and it needs to go away. Of course, you should always check to see if your input lengths are correctly corresponding to their appropriate columns.
Sanitizing Input vs. Sanitizing Output.
GCM = CBC + Authentication.
Nope, GCM = CTR + Authentication.
But in general you are right; CBC is an older mode that was invented back in the dark ages cryptographically speaking (no later than the 1970s), and is now disfavored because of the lack of built-in authentication and all the trouble that's been caused by padding oracles. One ...
This question is the Web 2.0 equivalent to "How do I disable right-click to stop people from stealing my HTML?"
The answer is that if you want people to be able to use your site, (on in this case, your data) you can't.
If your data is really so valuable that people want it badly, put it behind a paywall, charge a subscription to access it, and use a ...
Either way is fine, it just depends whether you want authentication to be stateless.
Advantages of JWTs:
Little or no database overhead.
Individual back-end components can validate the token in isolation, simply by knowing the secret key.
As authentication state is stored client-side, you cannot invalidate logins server-side.
Making inputs safe is better done as late as possible. That is, when data is output to the page. Globally "sanitizing" input data is bad because it is impossible to distinguish between good data and bad data at this stage (as you say, if you're allowing HTML to be entered by your users, the framework can't tell the difference between HTML that's meant to be ...
If you are echoing into JS inside a HTML document (as you are in your example), this is necesarry or you risk opening up a huge XSS vulnerability. Without this one, an attacker can post something along the lines of this:
Since PHP 5.4 this has been fixed, and slashes are escaped by default, but ...
Simply put - CBC came first. It is possible that you might have systems that only support CBC.
This would be the same question as "Why would I ever use RC4 and MD5 if AES and SHA-2 are available?" Compatibility and history. (Same with many other cipher choices.)
If all of your systems support AES-256-GCM, and have the resources to run it, and have a ...
Returning a HTML table will not prevent parsing. Actually nothing will prevent parsing, not even encoding your data as pictures rendered in a Flash viewer. But an HTML table is a piece of cake. Even Excel can understand a HTML table !
For your problem of how tiresome entering the data was, I'd say: well, suck it up. When you publish data, you cannot enforce ...
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 ...
The //<![CDATA[ hack is used in XHTML pages that have to parse as both HTML and XML.
In the HTML parsing rules, <script> and <style> are special “CDATA elements”, whose contents up to the next </ sequence (HTML4) or </script sequence (HTML5) are raw data, so if (x<y) can be written without any encoding; this would foul up XML parsers....
This is exploitable using Flash, according to https://code.google.com/p/browsersec/wiki/Part2#Same-origin_policy_for_Flash
The ability to make cookie-bearing cross-domain HTTP GET and POST
requests via the browser stack, with fewer constraints than typically
seen elsewhere in browsers. This is achieved through the URLRequest
API. The functionality, ...
If you want to be able to revoke previously granted tokens before their expiry date (a valid security concern), you'll need to include a database lookup to that, which negates one of the main advantages of JWT's, so you might decide to not use them in the first place.
Here's an article that talks about this case: https://www.dinochiesa.net/?p=1388
JSON (nominally) doesn't have a file signature.
File signatures (usually "magic" byte sequences with given offsets) exist in binary file formats; this includes executables, images, video, music, other media files, as well as numerous proprietary file formats.
The purpose of file signatures is to provide a would-be API for identifying the type of hard-to-...
Warning: This answer may be wrong and to optimistic. See 1lastBr3ath's answer above.
No, I don't think the application is vulnerable.
You can change the Content-Type header, e.g. using the fetch API. However, there are only three values that you can use for cross domain requests:
If you ...