I'm trying to validate a XAdES signature with a SignatureTimeStamp-element (which is a base64-encoded block). The Java-Lib xades4j basically does the validation for me. However, I'd like to manually inspect the timestamp (especially when validation fails). With inspect I mean to show the contents like the used certificates, their validity, the timestamp, etc.
What tool can I use? Does openssl do the trick? Can you give me an example of how to use it?
Xades4j uses Bouncy Castle to generate and validate timestamps. BC probably allows you to get that info from the timestamp token in the signature.
Related
Based on what i know (correct me if i am wrong) the 'access_token' is equivalent to the 'protected ticket' field in AspNetUser table. It's just hashed.
What i am planning to do is deserialize the protected ticket to get the access_token value.
I am trying to support a SSO scenario wherein, the user can access multiple application using the same access token.
Unfortunately, if the hash function used is a cryptographic hash, which the circumstances suggest, this is definitionally impossible (or should be...). Cryptographic hash functions are designed to be extremely expensive (ideally impossible) to reverse, and so the most effective method you have would be to attempt to brute-force the hash, I.e. running inputs through the hash function until you get one that produces the output you want. Even then, there's no telling how long it would take you to find it. It is strongly recommended not to write anything that depends on routinely brute-forcing a cryptographic hash.
Of course, its possible that the possible inputs are incredibly small (I.e. at most 16 bits or so), or that the function used is not a cryptographic hash function (I.e. its something like base64 encoding or rot-13). In that case, you might have a method to reverse the "hash" efficiently.
However, I strongly suspect that is not the case. In this endeavour, I think you are simply out of luck, and will have to find another way to get the functionality you desire.
I think I'm a bit late, but it should be possible. The data of ProtectedTicket will be secured by Microsoft.Owin.Security.ISecureDataFormat.Protect. It's not a one way hash. So it can be reversed. You can look this up on Github in the Katana project (Microsoft's Owin implementation):
https://github.com/aspnet/AspNetKatana/blob/dev/src/Microsoft.Owin.Security/DataHandler/SecureDataFormat.cs
As you can see, this interface provides a method Unprotect also. Didn't test it, but you could give it a shoot.
you can use the same token on the same apps as long the jwt token is signed with the same credentials (audience and secret) on every app. This allows every app to verify that the token is valid. this means, how-ever, that every app must know audience id and secret in the backend
I'm currently looking into server-side validation of a GoogleIDToken for Google Sign-in (Android & iOS). Documentation here
In the example, the "sub" field in the object returned by the Google API endpoint is read as a string, but it looks like it may actually be a (really big) number.
Some other tests using some users on my side also show big numbers.
Looking deeper in the Payload documentation, it looks like this value could be null, but outside of this possibility, can we assume that this string is actually a number?
This is important because we want to store it in a database, and saving it as a number might actually be more efficient than a string.
I work on the team at Google: this value should be stored as a string, it may be parseable as a number, but there is no guarantee, do not rely on that assumption!
If you're going to do arithmetic on it, then store it as a number. Otherwise, don't.
This is a general rule.
We have Lotus Notes signed document and user's public key.
What we need to do: enter the key into a field in a special application (it can be Lotus notes database or some special soft). Then we ask this special application: "Is this document really signed by this user with this public key?"
And our app must answer: yes or not.
We try to write this special application and we met few issues:
We have field named $Signature in the document, that is the hash of signed fields, encrypted with private key of the signer. I can see content of this field in document's properties. But I can't to extract it programmatically (I tried LotusScript and Java). And I didn't find any way to do it.
Therefore I just manually copied content of this field and pasted it into a field on a special form to further analyze. But there I met another problem. I don't know how to decrypt this signature. What algorithm Lotus uses to sign hash? If I will know the algorithm I guess I will be able to decrypt it with Java and get hash of signed fields.
And there will be one more problem I believe. I dont know how Lotus counts hash of fields. Does it use md5? I need to know it to be able to compare hashes and say did this user signed the document or not.
So. It's the interest task. But now it's impossible to solve it. There are 3 huge problems on the way. Can anyone help with them?
The answer is: don't try to do this yourself. Not the way you described it. There's an API to validate Notes signatures.
Just copy the document's UNID to your database, and then write code using the Notes C API to open the document and call the API function NSFNoteVerifySignature() to validate it. You can do this from Java using JNI or from LotusScript by following the techniques that are described here, or you can use the LSX toolkit, or just write a standalone C program.
You would have to use the Notes C API anyhow to deal with two of the three points that your raised:
You need the C API to get get at the contents of the $Signature item.
The signature is RSA.
You actually have two problems: the algorithm, and the input. You have to match them both. If I recall correctly, Lotus has described the hash algorithm as "modified MD2". Bear in mind, this goes back well over 20 years, and breaking compatibility is something that they don't like to do. It's possible that they've changed it when they upgraded RSA key sizes, but I don't recall hearing about that. But as I said, that's only half the problem. You need to get the raw input bytes in exactly the same format as the signature algorithm saw them, and for rich text fields this probably means reading raw CD records, which requires the C API.
I was reading about ASP.NET Script Exploits, and one of the suggestions is: (emphasis is mine; and the suggestion is #3 in section "Guarding Against Scripting Exploits
" in the web page)
If you want your application to accept some HTML (for example, some formatting instructions from users), you should encode the HTML at the client before it is submitted to the server. For more information, see How to: Protect Against Script Exploits in a Web Application by Applying HTML Encoding to Strings.
Isn't that really bad advice? I mean, an exploiter could send the HTML via curl or something similar, and the HTML would then be sent un-encoded to the server, which can't be good(?)
Am I missing something here or mis-interpreting the statement?
Microsoft is not wrong in their sentence, but on the other hand far from complete, and their sentence is dangerous.
Since by default, validateRequest == true, you indeed should encode special HTML characters in the client in order for them to get into the server in the first place and bypass validateRequest.
But - they should have emphasized that this is certainly not a replacement for server side filtering and validation.
Specifically, if you must accept HTML, the strongest advice is to use white-listing instead of black filtering (i.e. allow very specific HTML tags and eliminate all the others). Use of Microsoft AntiXSS library is highly recommended for strong user input filtering. It's far better than "re-inventing the wheel" yourself.
I don't think that advice is good...
From my experience I would totally agree with your thought and replace that advice with the following:
all input has to be checked server-side first thing on arrival
all input that can possibly contain "active content" (like HTML, JavaScript...) has to be escaped on arrival and never be sent to any client till full sanitazion took place
I would never trust the client to send trusted data. As you stated there are simply too many ways that data can be submitted. Even non-malicious users may be able to bypass the system on the client if they have JavaScript disabled.
However on the link from that item it becomes clear what they mean with point 3:
You can help protect against script exploits in the following ways:
Perform parameter validation on form variables, query-string
variables, and cookie values. This validation should include two types
of verification: verification that the variables can be converted to
the expected type (for example, convert to an integer, convert to
date-time, and so on), and verification of expected ranges or
formatting. For example, a form post variable that is intended to be
an integer should be checked with the Int32.TryParse method to verify
the variable really is an integer. Furthermore, the resulting integer
should be checked to verify the value falls within an expected range
of values.
Apply HTML encoding to string output when writing values back out
to the response. This helps ensure that any user-supplied string input
will be rendered as static text in the browsers instead of executable
script code or interpreted HTML elements.
HTML encoding converts HTML elements using HTML–reserved characters so
that they are displayed rather than executed.
I think that this is just a case of a misplaced word because there is no way you can perform this level of validation on the client and in the examples contained in the link it is clearly server side code being presented without any mention of the client.
Edit:
You also have request validation enabled by default right? So clearly the focus of protecting content is on the server as far as Microsoft is concerned.
I think the author of the article misspoke. If you go to the linked web page, it talks about encoding data before it's sent back to the client, not the other way around. I think this is just an editing error by the author and he intended to say the opposite.. to encode it before it's returned to the client.
I am developing an HTTP server application (in PHP, it so happens). I am concerned about table IDs appearing in URLs. Is it possible to encrypt URL variables and values to protect my application?
oh ok, so for sensitive information best to use sessions then, are table Ids etc safe to throw in the GET var?
Yes, sensitive information must not leave your server in the first place. Use sessions.
As for "are table ids safe in the URL": I don't know, is there anything bad a user could do knowing a table id? If so, you need to fix that. Usually you need to pass some kind of id around though, whether that's the "native table id" or some other random id you dream up usually doesn't matter. There's nothing inherently insecure about showing the id of a record in the URL, that by itself means absolutely nothing. It's how your app uses this id that may or may not open up security holes.
Additionally think about whether a user can easily guess other ids he's not supposed to know and whether that means anything bad for your security.
Security isn't a one-off thing, you need to think about it in every single line of code you write.
Sounds like you want to pass sensitive information as a GET param.
Don't do that - use $_SESSION if you can.
However, if you want your params encoded (i.e. => +) use urlencode().
$a = 'how are you?';
echo urlencode($a); // how+are+you%3F
You can encrypt what you pass before you transmit, or you can run the entire communication over an encrypted channel (https or ssh for instance).
Your GET variables are called whatever you choose to call them, and assigned whatever values you choose to give them. So, yes: they can certainly be encrypted or, if you'd rather, simply obscured. If you're planning to encrypt variables, then PHP has quite a few options available.
For the above, I'd recommend using something like urlencode.
In general I'd suggest using POST instead of GET, assuming you're getting your variables from a form element. On the other hand it might be even wiser to use session variables.
Maybe this article can give you more ideas...
http://www.stumbleupon.com/su/1nZ6bS/:1PcFQMI0:6oJD.Hd1/www.ibm.com/developerworks/library/os-php-encrypt/index.html/