0

I have created an online donation form for a Public Library. The form collects names, phone numbers, emails, addresses (a lot of personal info). The form is submitted to a PHP script that saves the information to CSV file and forwards the user to a PayPal checkout form for the donation amount they entered. People are unable to access the CSV file because there is a .htaccess file with the following: 

Order Allow,Deny
Deny from all

The people at the library would like to be able to access the information to send out thank you notes and for there records.

How can I give someone access to a file, on a website, securely without relying on a single password?

I though of using Basic Authentication but it relies on a single password that can be easily brute forced or too complicated to remember. Additionally, it could be socially engineered, or forgotten.

Keep in mind I do not have shell access to the server or to the Apache config files.

JBis
  • 640
  • 5
  • 17
  • 1
    It's not directly related to your question, but you might consider saving your CSV outside the webroot so that it isn't available in the public structure at all. You might know the .htaccess is protecting it, but someone stepping in after you're done with the project may not. Security misconfiguration is one of the OWASP Top 10. A database (even SQLite) might be better than a CSV for your purposes, though. – nbering Apr 03 '18 at 02:10

2 Answers2

3

The canonical answer would be — using cryptographic tokens. In some countries or organisations, such tokens or ID cards may already have been issued and widely available.

But given the context, you should probably consider alternative delivery mechanisms. For example, an automated nightly email to a librarian, with the newly added relevant entries in it, does not need introducing any new authentication mechanisms, has a fairly limited — and generally well-understood — maintenance expense and attack profile, meshes well with many modern styles of office routine, and has only one moving part that can be directly nudged by an attacker from the website end. You should consider if the email needs to be encrypted or not, and which fields are relevant in its context, of course.

dig
  • 355
  • 1
  • 6
  • +1 for simplicity – nbering Apr 03 '18 at 02:17
  • 1
    Other delivery mechanisms that would allow more complicated permissions mechanisms for sharing would be adding the data to a Google Sheet, or as a file in Dropbox. Both have APIs you could use to add content, and then the user account that owns the file would control who can access it. This requires more work for you than email, though. – nbering Apr 03 '18 at 04:15
  • +1 for Google Docs. May actually use this in a couple different projects I’m working on. Did not know they have an API. – JBis Apr 03 '18 at 12:29
1

Simple: Use the IP number of the library in question, to authorize them access.

However, the Order/Deny is depreciated and you need to use the following instead (with IP access added) in the .htaccess:

<RequireAny>
    Require ip XX.XX.XX.XX/XX  #LIBRARY's IP1
    Require ip XX.XX.XX.XX/XX  #LIBRARY's IP2
    Require ip XX.XX.XX.XX/XX  #LIBRARY's IP3
</RequireAny>

Also ensure that these IPs do not map up to public terminals unless public terminals are locked down tightly. In that case, excempt them. With something similiar to:

<RequireAll>
  Require not ip XX.XX.XX.XX/XX #LIBRARY's PUBLIC TERMINAL
  <RequireAny>
    Require ip XX.XX.XX.XX/XX  #LIBRARY's IP1
    Require ip XX.XX.XX.XX/XX  #LIBRARY's IP2
    Require ip XX.XX.XX.XX/XX  #LIBRARY's IP3
  </RequireAny>
</RequireAll>

If the apache is running an old version, and you must use the order/allow/deny directives, use:

Order Allow,Deny
Allow from XX.XX.XX.XX/XX #LIBRARY's IP1
Allow from XX.XX.XX.XX/XX #LIBRARY's IP2
Allow from XX.XX.XX.XX/XX #LIBRARY's IP3
Deny from XX.XX.XX.XX/XX #LIBRARY's PUBLIC TERMINAL

Note that due to "Order Allow,Deny" you don't need a Deny from all, which would unconditionally deny the request even if some IPs match. (the opposite, to default allow, is Order Deny,Allow).

sebastian nielsen
  • 8,779
  • 1
  • 19
  • 33
  • Does this not rely on the single password of the library’s (WiFi) network? – JBis Apr 02 '18 at 20:41
  • First: The wifi network is restricted to that particular location, making it more difficult to exploit, as physical presence is required in addition to knowing the password. Second: You can in the same way as for public terminals, except their WiFi network from access, so only their hardwired computers have access. Because the library most likely have their WiFi on a separate network than the hardwired network to more easily track abuse etc. (unless its a super small library which only have a single IP outwards) – sebastian nielsen Apr 02 '18 at 21:37
  • Ok thank you. Will check on the public terminal thing. But remember the physical location is a **Public** library. – JBis Apr 02 '18 at 21:48
  • The best thing you can do is to talk to the library's IT management and ask for which IPs they use. Maybe you could even get to borrow their wifi, and you can visit a site like whatismyip.com and then ask them to visit the same site from their hardwired computers. And then visit whatismyip.com from their public terminals. And then write down the IPs. And compare them and also look them up on a whois site to see the whole applicable range. – sebastian nielsen Apr 02 '18 at 21:51
  • 1
    Given that it is PII, ip-based security seems unsuitable. All you'd need to do is connect to the wifi (or an open ethernet jack) and you'd have access to the list. Even a shared password would seem to be more suitable. – nbering Apr 03 '18 at 02:14
  • @nbering Thats why its important to segment off the access so only the librarians have access. On medium and large libraries, its Always segmented off so the public wifi and/or public jacks are using other IPs than the librarians. Just so it should be safe to use IP-based access. The problem with a shared password is that once a librarian ends their employment, the password needs to be changed. With IP-based access, its automatic since its instead tied based on physical location - terminate an employee and he loses access "automatically". For PII its under certain circumstances OK w. IP-access – sebastian nielsen Apr 08 '18 at 21:22
  • @sebastiannielsen I don't disagree in principle, but there's a lot of prerequisites to make this "simple" model secure. And there's nothing in the original post to suggest that this Public Library is mature enough in the IT department to be segmenting networks. – nbering Apr 08 '18 at 21:27