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 ...
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 ...
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. ...
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 ...
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
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 ...
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 ...
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.
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-...
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 ...
An XSS vulnerability usually consists of two components: A backend which reflects user-provided strings without filtering them and a frontend which puts that input into a HTML document without filtering it.
So you don't just need to look at what the server does, you also need to look at the application which consumes that JSON response.
Is there a ...
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.
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 ...
A more detailed answer can be found here.
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 ...
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.
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 ...
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 ...
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
How does a JTI prevent a JWT from being replayed?
How often should the JTI field be regenerated? On every request? or only when a new token is generated?
I believe the answers to these two questions will depend on the application itself.
For example, if it has been programmed to only receive messages that have a unique JTI, then a replay of the same ...
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-...
The JSON issue that led google to prepend while was a same-origin breakdown in early versions of firefox (1.5 and 2b specifically) where the JSON file could be loaded as a normal script tag from off-site, and have its data reachable.
Normally JSON files don't "tell" the JS engine to do anything if loaded as a script, so they have/leave no reference to ...
If there is code executing in the same context of your web application, whether it was part of a XSS attack in the browser, or some malware/virus on the users machine, it would be difficult (impossible?) to differentiate those requests from your own.
If the attacker has access to the computer, they could also just steal the data from your applications ...
You should look at oauth 2.0 (RFC 6749) it has a number of flows which could meet your requirements.
Firstly you need to know if the clients are public or confidential. Issuing client api keys as you are doing is pointless if the clients are web browsers or apps downloaded to mobile devices as the secret can't be maintained. If they are servers then api ...