4 ms·

Edit: fixed now. Original: Please don't upload any private or confidential pdfs right now. I emailed OP two security concerns that trivially allow anybody to s

Edit: fixed now. Original: Please don't upload any private or confidential pdfs right now. I emailed OP two security concerns that trivially allow anybody to see any of the converted pdfs.

baicunko 6y ago
Fixed. Sorry, forgot to configure nginx.
- thebigshane 6y ago
  isn't this a problem? https://github.com/baicunko/scanyourpdf/blob/master/convertpdf/settings.py#L23 https://github.com/baicunko/scanyourpdf/blob/master/convertp...
  - rozab 6y ago
    I thought github had hooks for this kind of thing now? I remember it caught a private key I tried to push to a similar django repo (not for a prod site or anything), and that was about 2 years ago
    - dewey 6y ago
      I think this only works for secret keys that have a certain pattern like AWS keys.
  - baicunko 6y ago
    I manually modified the private key on the server before publishing here. Still learning on ENV VARIABLES and I couldn't make them work!
    - vmception 6y ago
      haha this is like those domain name search websites that just automatically register the good sounding domain names for themselves once the user types it in. do you OP! I think it still provides a service, enjoy all the secrets
      - kchr 6y ago
        If you upload secrets to public sites you're in trouble regardless of whether they claim "secure" hosting or not... And what makes you think the operator has nefarious intent?
    - 411111111111111 6y ago
      You might want to just switch to a dotenv library. Quick Google for Django yielded https://github.com/jpadilla/django-dotenv https://github.com/jpadilla/django-dotenv
      - capableweb 6y ago
        Dotenv libraries are just for dev and other similar environments. In production you should still use normal environment variables (or whatever system you use to load your configuration), as dotenv files stay on the filesystem and sometimes even committed to your SCM.
        deleted 6y ago
        [deleted]
lewiscollard 6y ago
It's still far short of being suitable for use of any private documents. https://github.com/baicunko/scanyourpdf/blob/master/pdfwebsite/views.py#L45 https://github.com/baicunko/scanyourpdf/blob/master/pdfwebsi... This is rather less than secure; output files are named, e.g., "Scan_2020512_{four random lower-case letters}.pdf" into a web-server-readable directory. That gives a total of 456976 different possible filenames on a day. It's more than feasible to brute-force that many filenames in the hour before files get deleted. OP: I don't think randomly-suffixed file names are an inherently bad way to approach this. But you should definitely consider using a longer random string, and definitely consider not using the `random` module too (it is not secure and is not intended to be).
- baicunko 6y ago
  Thank you for the comments. I agree with you, I will decrease how long the file is in the server (I just hit 40gb from hacker news) as well as implement rate limiting to prevent any brute force
  - lewiscollard 6y ago
    Rate limiting (if by that you mean at the firewall or the web server) is not the way to do it. That shifts the problem somewhere else in the stack, into a place that isn't under version control in the same repository. Consider: If you moved this on to another server, would you remember to enable rate limiting there? If someone else uses your code, will they know to enable rate limiting? Rate limiting isn't a bad idea, but your security should not depend on it, especially as you have a way of securing it in your application. base64.b16encode(os.urandom(8)) will give you a 64-bit, filename-safe, as-close-to-random-as-reasonable suffix that should be long enough to make it brute-force-proof :) The same reasoning applies to the cron job (I presume) that is cleaning your files - that's something you have to remember to set up for future (re-)deployments. Edit: I'd also like to add that showing your code on HN takes bravery and this is, in fact, a neat tool that solves a problem I really wish didn't exist. So, good work on both counts :)
    - OriginalPenguin 6y ago
amhokies 6y ago
You probably shouldn't be uploading sensitive pdfs regardless.

Edit: fixed now. Original: Please don't upload any private or confidential pdfs right now. I emailed OP two security concerns that trivially allow anybody to see any of the converted pdfs.

baicunko 6y ago

Fixed. Sorry, forgot to configure nginx.

thebigshane 6y ago
isn't this a problem? https://github.com/baicunko/scanyourpdf/blob/master/convertpdf/settings.py#L23 https://github.com/baicunko/scanyourpdf/blob/master/convertp...
- rozab 6y ago
  I thought github had hooks for this kind of thing now? I remember it caught a private key I tried to push to a similar django repo (not for a prod site or anything), and that was about 2 years ago
  - dewey 6y ago
    I think this only works for secret keys that have a certain pattern like AWS keys.
- baicunko 6y ago
  I manually modified the private key on the server before publishing here. Still learning on ENV VARIABLES and I couldn't make them work!
  - vmception 6y ago
    haha this is like those domain name search websites that just automatically register the good sounding domain names for themselves once the user types it in. do you OP! I think it still provides a service, enjoy all the secrets
    - kchr 6y ago
      If you upload secrets to public sites you're in trouble regardless of whether they claim "secure" hosting or not... And what makes you think the operator has nefarious intent?
  - 411111111111111 6y ago
    You might want to just switch to a dotenv library. Quick Google for Django yielded https://github.com/jpadilla/django-dotenv https://github.com/jpadilla/django-dotenv
    - capableweb 6y ago
      Dotenv libraries are just for dev and other similar environments. In production you should still use normal environment variables (or whatever system you use to load your configuration), as dotenv files stay on the filesystem and sometimes even committed to your SCM.
      - deleted 6y ago
        [deleted]

lewiscollard 6y ago

It's still far short of being suitable for use of any private documents. https://github.com/baicunko/scanyourpdf/blob/master/pdfwebsite/views.py#L45 https://github.com/baicunko/scanyourpdf/blob/master/pdfwebsi... This is rather less than secure; output files are named, e.g., "Scan_2020512_{four random lower-case letters}.pdf" into a web-server-readable directory. That gives a total of 456976 different possible filenames on a day. It's more than feasible to brute-force that many filenames in the hour before files get deleted. OP: I don't think randomly-suffixed file names are an inherently bad way to approach this. But you should definitely consider using a longer random string, and definitely consider not using the `random` module too (it is not secure and is not intended to be).

baicunko 6y ago
Thank you for the comments. I agree with you, I will decrease how long the file is in the server (I just hit 40gb from hacker news) as well as implement rate limiting to prevent any brute force
- lewiscollard 6y ago
  Rate limiting (if by that you mean at the firewall or the web server) is not the way to do it. That shifts the problem somewhere else in the stack, into a place that isn't under version control in the same repository. Consider: If you moved this on to another server, would you remember to enable rate limiting there? If someone else uses your code, will they know to enable rate limiting? Rate limiting isn't a bad idea, but your security should not depend on it, especially as you have a way of securing it in your application. base64.b16encode(os.urandom(8)) will give you a 64-bit, filename-safe, as-close-to-random-as-reasonable suffix that should be long enough to make it brute-force-proof :) The same reasoning applies to the cron job (I presume) that is cleaning your files - that's something you have to remember to set up for future (re-)deployments. Edit: I'd also like to add that showing your code on HN takes bravery and this is, in fact, a neat tool that solves a problem I really wish didn't exist. So, good work on both counts :)
  - OriginalPenguin 6y ago

amhokies 6y ago

You probably shouldn't be uploading sensitive pdfs regardless.