I'm using origami to digitaly sign a pdf.
Is it possible to use OpenSSL::PKCS7.sign to sign a pdf and pass as a parameter or as an attribute an specific date to be the date of signing?
If not is there any way of accomplishing this?
I have been searching but found nothing on it.
What you want makes no sense from security point of view. You are actually asking "how do I spoof signing time in my documents". Well, you can't do this without capturing control over one of authorized TSA (timestamping authorities) in one way or another.
Update: In general it's possible to put any time to PDF signature as one of its attributes. As I look into Origami's source code, I don't see any way to put time to the signature.
Related
I use Vaadin7 and I develop my application and test it with Edge. When I enter information in my input fields, I remark than Edge store data like this (see screenshot). My question is can we block with Vaadin the message in my input fields ? I don't want change parameter in my browser Edge but I would like to do it in my code.
Best regard.
Thank you
Screenshot
It's a tad complicated.
First of all, there is no standard way of doing this. There is the non-standard attribute autocomplete that, when set to off, seems to work (or at least have worked at some point in time, see Disable browser 'Save Password' functionality) but only in non-edge browsers. One trick seems to be to use some kind of hiding/obfuscation (which I would consider a bad idea and probably leads to accessibility issues) like mentioned here: https://stackoverflow.com/a/2555771/10493440. A current approach is using invalid data: https://stackoverflow.com/a/52608082/10493440
I would not suggest any of that as it might break at any time without warning. Changing your browser's setting is the proper way to go even if that might feel unsatisfactory.
For the Vaadin part: Give your field an ID and then apply any of the suggestion above via JavaScript.execute(...) method.
Guys i'have a question.
I'm currently buiding a wizard that has 5 step's until being completed.
The user starts by the first step where he generates the entry id.
From there on i start passing the id over the url like this:
host.com/{controller}/{view}/{id}
This is how my url looks like after the step1,
------- currently at view step2 passing the id=120
host.com/{controller}/step2/120
This isn't safe because as you know, anyone can change the id and affect other users's entries. Ofc, it can be quickly solved by reading if the authenticated user is proprietary of the entry that he must be trying to access in each view.
Now, my question is... is there a better way to do this?
Any tips for future work?
Is what i'm doing enougth?
(begginer doubt praying for a expert awnser)
Cheers
...It can be quickly solved by reading if the authenticated user is proprietary of the entry that he must be trying to access in each view.
Yes, that's true. You should start there.
Here are some other things that you could do:
You could make your entry ids Guids instead, so that a would-be hacker would never try to guess an entry id.
Because using GET for sensitive data is a bad idea, you could, as endyourif suggests, pass the entry ids with hidden fields instead.
If you are truly concerned about the user altering the ID in the URL, then you must spend the additional time adding an "isOwnedBy" like functionality.
As an additional security measure, you could pass it via a hidden variable in the form so it is at least not as easy to change as well.
Edit: I like #LeffeBrune's suggestion of encrypting the idea as well. However, I still suggest that the validation is performed on the function to ensure the user owns the object. It's just good practice.
I need to know how to use each and every attribute of Struts2 tags. I
have gone through all possible websites by searching via Google, But
no one has understandable explanation or examples of each and every
attributes of each struts2 tags.
for example: In "optiontransferselect" tag, for
allowAddAllToRight attribute I have no idea what String do I need to give for it.
here is one of the site I refered...
If you want to understand every single option, do two things:
Use every single option.
Read the source code.
When something is listed as "enable", it's almost always a true/false value, as it is in this case. Why it's listed as a string, not sure; either an issue with the annotation processor, or it was added and the type conversion was done manually, or...?
While I (sort of) understand the motivation for wanting to understand "each and every attribute" of each tag, IMO your time would be better spent learning more important framework details.
I am afraid you will find them at anywhere as these attributes have been defined and provided based on generic needs and its quit possible that some one need few of them and some need others.
i even never used all of the tag properties and in most of the cases we end up using few as per our choice.
If you want to find what each and every property/ attribute making end effect best way is to create a demo struts2 application pick up few tags go to struts2 tag reference page read there description and start playing with them and see how things are changing and check generated HTML code.
There is no other shot-cut for this.
But why you need to know all the properties? i am just curious
Struts2 tag refrence
What is the following portion of a Gmail URL for?
https://mail.google.com/mail/?**zx**=1efobg68r40co&**shva**=1#inbox
If you change it, nothing happens!!
I know Gmail is not an Open-Source program so we can't trace the code. But every website try to make the URL shorter so they ideally shouldn't add redundant data to the URL. At the same time they don't make any difference nor error if they change.
Edit: I know it's a parameter for a scripting language since I'm a PHP developer but as a developer I don't EVER add a useless parameter and I think it's obvious/primitive sense!
The acronym stands for "Should have valid authentication" as noted here:
http://googlesystem.blogspot.com/2010/07/gmails-shva-parameter.html
As others have noted, 1 is the default value.
If I'm remembering correctly, back when they were working on the current version of the interface, you could preview it by setting shva=2 instead of the default. That version is now the default and you can't get the old version, so shva does nothing now.
It may be used again in the future, who knows?
But every website try to make the URL shorter so they ideally shouldn't add redundant data to the URL...
This is self-evidently not true. Look at StackOverflow URLs for a perfect example. This post:
http://stackoverflow.com/questions/1692968/shva-in-gmails-url-what-is-this
could just as easily be (it works):
http://stackoverflow.com/questions/1692968
I don't think anyone worries these days about the extra couple bytes of data involved with an extra query string parameter.
Some of them saying it is" should have valid Authentication". We shall consider it OK.
But the real expansion of shva is "security host verification and authentication".
It always comes when you open Gmail.
We won't know what it 'exactly' means unless someone inside Google answers your question. But my guess would be that it has to do with security and encryption. Nothing happens when you change it because it is part of the cookie as well. So when you change it they must also compare it with what is set in the cookie.
"shva" is an acronym for "should have valid authentication". Apparently, the parameter is only included after a successful authentication.
The 1 is the default value applied to the parameter check. It's also a shorthand way for programmers to say true, like when you have successfully logged in.
The other part, #inbox, tells Gmail to load up your inbox as the first screen. You can change that to one of the other folders (or even labels you've created) to load them up.
E.g., https://mail.google.com/mail/?shva=1#sent will show your Sent folder items.
https://mail.google.com/mail/?shva=1#label/narwhals will load up your "narwhals" label.
Gmail, like many web services, serves a standard interface that will change to show only your information and data when you've logged in.
The particulars are referenced on their end through the use of an ID from the cookies or sessions generated after the login screen.
I'm building a publicly available web app. Because of this, I'll be validating every field as exhaustively as I can. I mean, if someone enters something that isn't valid, they will know exactly what it was (making it clear what they need to fix).
I've followed Scott Guthrie's examples in the NerdDinner eBook. I love the idea of having all my validation in the core class files (as a partial class).
The validation I'm performing is this:
Min value - make sure strings are at least a certain length
Max value - make sure strings are under a maximum length (based on field properties in the DB)
int checks - make sure integer fields can be correctly parsed to int
file extension - make sure the uploaded file extensions are of the correct type
My question is, what are the typical validation checks you make in your web apps? Maybe I'm completely overlooking something. ;)
Thanks in advance!
You should try to use existing frameworks as much as possible for validation. Writing a comprehensive validation library is a lot of hard and time-consuming work. It's one of those things that are best left to a team of people dedicated to developing it such as the jQuery validation plugins and projects like that. There are a lot of really nice validator libraries out there already that could save you a lot of time and effort.
There is an MVC validator toolkit project on codeplex you may find helpful. CodeProject has a tutorial on it if you want to read more into it. You can also check out xVal, as one of the commenters mentioned.
If you have a specific reason you need to write validation in-house, or you aren't convinced by what I said above, a few that I find useful are:
Required field validation, obviously. You might already have this by just checking for minimum length in your fields.
Generic regular expression validation. Make sure you have some way to perform this kind of validation generically. This will help you in case there is some specific field that needs a unique form of validation found no where else in your site. Make sure your API is flexible enough to add specific regular expression based validation.
Email. You'll need this.
Phone numbers. These can be tough because of all the forms they can come in (all numeric, sometimes with alpha characters, sometimes international numbers that follow different formats)
Dates & times are important also, however you should consider using some sort of date/time picker to reduce the possibility of error by not allowing the user to type a value.
Make sure you include validation capabilities for non-textbox related fields, such as drop-down lists, radio buttons, check boxes, etc. I've forgotten these in the past just out of oversight, but they do become important.
Matching fields. For example, when confirming a password, both fields should match. This won't be used in just one page. Think about password resets, administrative pages, user control panels, etc.
Although somewhat complex, you might also want to include sequence validation. For example, perhaps some options on your site require you to select other options first. Another example is that certain options should only be selectable if you first choose some other combination of options. This is something that you may not be able to include in a generic API, but it's something to think about.
You'll want to check for SQL injection, XSS, and CSRF. You can use these tools for Firefox to help you test those. Then there are also things like making sure that the username doesn't equal the password, login throttling, etc. Validating your CSS and XHTML isn't bad either, though I don't think that's quite what you meant.
In addition to what others have mentioned, don't forget to validate items that depend on one another. That is, consistency of input values. If the user enters a maximum and a minimum, for example, don't just check the two values independently against their legal max and min, but also check them against each other to ensure that the values entered are logically consistent.
For hostnames, you may want to validate that DNS returns an IP address. If it does not, let the user know but don't necessarily reject the hostname for this reason. Maybe the user is pre-configuring something that doesn't exist yet. It depends on the specific application.
That is, in addition to syntactic validity, you can also check that the values entered are meaningful and consistent with each other.
Another thing you can do if you go all out is to only allow digits to be entered in numeric fields, only allow digits and "-" in credit card or phone number fields, and so on.
And always, always allow the user to enter input in the most familiar format, even if you later have to strip out extraneous data. For example, let the user (but don't require the user to) enter a phone number is 1-800-555-1212 even if you later strip out the "-" characters.
Not really sure what this has to do with asp.net-mvc but...
I always try to avoid over-validating (obviously you need to do the simple sanity stuff to make sure there are no db errors). It is a field by field decision according to your business rules. Some fields will need to have strict validation rules, like a credit card number. But just always think about how the validation will server the user. There is rarely a need for the regex to match all possible email addresses - it is really annoying when a site won't allow + signs in your email. In most cases, your app will be just fine if you let people put in phone numbers how they want. And always second guess yourself when you're about to put a required rule on a field.
I recommend the entlib validation application block for a easy to use and extend framework.