5 Replies Latest reply on Jan 26, 2010 4:50 PM by brogers123

    Reader 9.3 Security Question


      The new version of Adobe Reader (9.3) has some new security restrictions to do with accessing untrusted sites.


      This has dealt quite a big blow to my current process which is (in short)...


      1) Create PDF with form that sends data to my server
      2) Email PDF to client
      3) Client enters some information, data gets sent to my server in form submit and I return an FDF to the PDF
      4) PDF uses javascript to decipher message from FDF and popup a confirmation


      So my problem now is that the security popup (“Options” are “Trust this document one time only” or “Trust this document always”) requires the user to re-enter their password once one the said option is chosen, which seems to re-open the PDF. Because of this closing and opening of the PDF, the FDF data is lost and I don't get any chance to look at that information.


      Also, any information that is entered into the form is also lost once the pdf "re-opens"


      Has anyone else had any experience with this so far? Is this by design that all form entered data goes missing?

        • 1. Re: Reader 9.3 Security Question
          brogers123 Adobe Employee

          Hi: There are two solutions:

          • Trust content from the host by setting up privileged locations prior to initiating the workflow. As a response to increasing security concerns, Adobe is recommending as a best practice that enhanced security remain enabled and that workflow locations be specfically trusted. For more information, see the quick key or FAQ here: http://learn.adobe.com/wiki/display/security/Application+Security+Library. The longer guide may also be helpful.
          • Turn off enhanced security. While tuning a workflow that's already deployed may be annoying, do so is often a better choice than leaving yourself open to cross site scripting and other types of attacks.
          • 2. Re: Reader 9.3 Security Question
            alexpapa_tech Level 1

            These solutions are fine when the scenario exists for the sender of the documents to have any control over the recipients installation of Reader.


            But consider this application:


            Company A generates PDF Bills and e-Mails them to Company B's client base. For arguments sake let's say these are end consumers and not corporate. Now the Bill may be a static bill or it may contain some customer feedback information, such as a survey.


            The information is entered into the form fields and submitted to a CGI script which returns an FDF containing key/value pairs indicating whether the survey was completed successfully, along with a confirmation number (generated at the server side).


            With the new security restrictions, the customer will see the yellow popup when the FDF is returned (meaning that the receiving server already has the information). They then have the choice to trust this PDF or not (considering it is an emailed file, trusting once or always is irrelevant).


            It's at this point that I think Adobe have overlooked the new functionality. I understand that not trusting the PDF should block the FDF contents from the form. BUT, trusting the PDF should allow the FDF contents to be injected, whether script or key/value pairs.


            The problem is that the PDF is "re-opened" (best way I can describe it, as if there is a password on the file it is requested again). This means that not only does the FDF not complete it's action, but the form fields that the end-user inputted are all cleared, with no indication that the submission was successful or not.


            From a customer point of view, it looks like an error or a bug. From a provider point of view, it means duplicate submissions at best, and probably an unwillingness to use the solution in the future.

            • 3. Re: Reader 9.3 Security Question
              brogers123 Adobe Employee

              Hi: You are correct. It wasn't clear to me which person in your workflow was experiencing the point of failure (lost data) and that you control one of the servers. Your solution can be solved with a server side fix. If you deploy a cross domain policy file on the server which trusts the other involved server  you should be able to set up a viable workflow. For example, Server A could host a crossdomain.xml policy file that trusts http://serverB.com. Again, for details, see the cross domain documentation at http://learn.adobe.com/wiki/display/security/Application+Security+Library.

              • 4. Re: Reader 9.3 Security Question
                alexpapa_tech Level 1

                thanks, I understand that process as well,


                but in this case, the PDF's are not hosted, they are sent via e-mail, so are local files essentially.


                Do you see any other work-around. Is cross-domain policy even possible with local files in this scenario?

                • 5. Re: Reader 9.3 Security Question
                  brogers123 Adobe Employee

                  The solution here is to use a cross domain policy file to assign trust. Allow your clients (customers) to trust a pdf, fdf, xfdf, ect. by certifying the doc sent to the client and placing the fingerprint of the certificate used to certify the document to trust in the cross domain policy file.For example, if you returning an FDF with data to your customer's PDFs, certify the FDF and place its cert fingerprint in the cross domain policy file.


                  This technique is described briefly in the Enhanced Security Guide and more fully in the Cross Domain Security Guide. Both are located here: http://learn.adobe.com/wiki/display/security/Application+Security+Library.


                  The big picture is this:


                  Adobe turned on enhanced security by default to protect users’ machines and data. As with any security restriction, the protection has the possibility to break certain workflows that were designed to function in an unsecure way over a network. However, Adobe is providing several methods for establishing trust between files, folders, and hosts to enable these workflows while retaining a desirable level of security. Workflow onwer actions vary depending on the workflow components you control:


                  • When you control the clients: Pre-configure privileged locations.
                  • You control the server: Use a crossdomain.xml policy file.
                  • You control the entire workflow: Set up a certified document workflow where end users trust the signing certificate for privileged networked operations, configure privileged locations for all clients, use a crossdomain.xml policy file.
                  • You don’t control the client or server: In this case, you have to encourage users to do the right thing prior to interacting with your PDF. For example, prior to having end users fill out a form whose submittal will result in data returning back to that user, have them first trust your server as a privileged location.


                  These methods are described more fully here: http://learn.adobe.com/wiki/display/security/Application+Security+Library.