I have PDF document with one LTV signature (document contains DSS dictionary). Why iText check if the signature covers whole document returns FALSE, if the only information added after signing was DSS? No other changes were made in the document.
In iText 7.1.7 method SignatureUtil.signatureCoversWholeDocument does not take into account DSS byte range. For me DSS is part of the signature and validation check should count with this.
How to ignore/exclude DSS bytes at the end of the PDF document when calling signatureCoversWholeDocument method?
Why iText check if the signature covers whole document returns FALSE, if the only information added after signing was DSS? No other changes were made in the document.
But you yourself say that something has been added after signing. Thus, the signature does not cover the whole document. Thus, if iText reported something different here, it would be wrong.
In iText 7.1.7 method SignatureUtil.signatureCoversWholeDocument does not take into account DSS byte range. For me DSS is part of the signature and validation check should count with this.
DSS is not part of the signature. Please re-read the specifications.
SignatureUtil.signatureCoversWholeDocument checks whether the signed byte ranges of the given signature encompass the whole PDF except the gap left during signing for embedding the CMS signature container.
If there is any addition to the document thereafter, the method will return false even if the addition only contains DSS, actually even if the addition contains no new objects, and also even if only a trailing eol is added.
How to ignore/exclude DSS bytes at the end of the PDF document when calling signatureCoversWholeDocument method?
What you need is something else. What you need is code that checks whether additions applied to a PDF after a signature are allowed or disallowed. iText does not contain a method for that, so you have to implement that code yourself or look for a third-party implementation.
Please be aware that this task is not easy. Even the implementation thereof in Adobe Acrobat (which may serve as a kind of reference here) errs every so often, and in either direction.
Related
After having read a lot of documents from yubico, I have the impression that they want their servers to be used to verify YubiKey's OTPs.
All the documents and code I found don't really explain how exactly the OTP is built or verified.
For example "OTPs Explained" states that a checksum is appended at the end, but it does not tell how the format exactly looks like, or how the checksum is computed exactly.
So is there a useful specification out that allows me to write code to verify an OTP sent from a YubiKey 5?
This is the signature i got when i am signing a pdf
From which, is there any way to get Signatory(in my Signature Suniiii). Now I am able to extract location, date and Reason except Signatory.
First of all, the image you see includes textual information which can be freely chosen by the signing application. Usually for such visualizations the text is chosen to match the information invisibly stored in the signature field but some mischievous signer may insert differences. Thus, you first have to decide whether you want to get the text from the signature appearance or the values stored invisibly in the field.
If you want to read the exact text from the visualization, simply use the code from the answers to the question "Get Layer2 Text (Signature Description) from signature image using itextsharp".
If you want to read the exact content from the invisible field information, use the values of the signature field value dictionary as you already do for location, date, and reason, and also read the CMS signature container from the Contents, extract the signer certificate, and read its owner DN.
I am attempting to preview a track via the 7digital api. I have utilised the reference app to test the endpoint here:-
http://7digital.github.io/oauth-reference-page/
I have specified what I consider to be the correct format query, as in:-
http://previews.7digital.com/clip/8514023?oauth_consumer_key=MY_KEY&country=gb&oauth_nonce=221946762&oauth_signature_method=HMAC-SHA1&oauth_timestamp=1456932878&oauth_version=1.0&oauth_signature=c5GBrJvxPIf2Kci24pq1qD31U%2Bs%3D
and yet, regardless of what parameters I enter I always get an invalid signature as a response. I have also incorporated this into my javascript code using the same oauth signature library as the reference page and yet still get the same invalid signature returned.
Could someone please shed some light on what I may be doing incorrectly?
Thanks.
I was able to sign it using:
url = http://previews.7digital.com/clip/8514023
valid consumer key & consumer secret
field 'country' = 'GB'
Your query strings parameters look a bit out of order. For OAuth the base string, used to sign, is meant to be in alphabetical order, so country would be first in this case. Once generated it doesn't matter the order in the final request, but the above tool applies them back in the same order (so country is first).
Can you make sure there aren't any spaces around your key/secret? It doesn't appear to strip white space.
If you have more specific problems it may be best to get in touch with 7digital directly - https://groups.google.com/forum/#!forum/7digital-api
I'm building a simple image file upload form. Programmatically, I'm using the Laravel 5 framework. Through the Input facade (through Illuminate), I can resolve the file object, which in itself is an UploadedFile (through Symfony).
The UploadedFile's API ref page (Symfony docs) says that
public integer | null getClientSize()
Returns the file size. It is extracted from the request from which the
file has been uploaded. It should not be considered as a safe
value. Return Value integer|null The file size
What will be these cases where the uploaded filesize is wrongly reported?
Are there known exploits using this?
How can the admin ensure this is detected (and hence logged as a trespass attempt)?
That method is using the "Content-Length" header, which can easily be forged. You'll want to use the easy construct $_FILES['myfile']['size']. As an answer to another question has already stated: Can $_FILES[...]['size'] be forged?
This value checks the actual size of the file, and is not modified by the provided headers.
If you'd like to check for people misbehaving, you can simply compare the content-length header to your $_FILES['myfile']['size'] value.
I am using iText for PDF signing.
My PDF form has 3 signature fields. The first two fields are for approval signatures and the last field is for certification signature. Certification signature is always signed after the approval signatures and Append mode is set to true for all signatures.
My question is after the certification signature is signed (certification level set to CERTIFIED_NO_CHANGES_ALLOWED) the validated approval signatures will become invalidated while the certification signature is validated.
How should I go about fixing this?
Certification signature is always signed after the approval signatures
This is not allowed.
The PDF specification ISO 32000-1 indicates that
The signature dictionary of a certification signature shall be the value of a signature field and shall contain a ByteRange entry. It may also be referenced from the DocMDP entry in the permissions dictionary (see 12.8.4, “Permissions”). The signature dictionary shall contain a signature reference dictionary (see Table 253) that has a DocMDP transform method.
(section 12.8.1 Digital Signatures / General)
The DocMDP transform method shall be used to detect modifications relative to a signature field that is signed by the author of a document (the person applying the first signature). A document can contain only one signature field that contains a DocMDP transform method; it shall be the first signed field in the document. It enables the author to specify what changes shall be permitted to be made the document and what changes invalidate the author’s signature.
(section 12.8.2.2.1 Digital Signatures / Transform Methods / DocMDP / General)
I.e. a certification signature has a DocMDP transform method and the signature having a DocMDP transform method must be the first one signed in the document.
What you try to achieve, though, might be possible otherwise if PDF2 features are ok with you, cf. Bruno's white paper Digital Signatures for PDF documents section 2.5.5 Locking fields and documents after signing:
Since PDF 1.5, it’s possible to lock specific fields when signing a document. In PDF 2.0, there will be a new feature that allows you to define the document-level permissions that are already available for certification signatures, but now also for approval signatures.
For details (which go beyond the size of an answer here) read that section...