0

I'm using Flask-HTTPAuth (https://github.com/miguelgrinberg/Flask-HTTPAuth) to protect my API with a username and a password. Since this is running on port 8080, I've opened the port on my VM and made it public. Is there anything else I can do to make the API more secure?

Btw I'm using Tornado in front of Flask to act as a scalable server. And I'm the only one consuming the API because of which having a single username-password pair is a viable option for me.

Thanks.

Edit - Is there anything I can do on Windows Firewall to make port 8080 more secure?

90abyss
  • 7,037
  • 19
  • 63
  • 94
  • There's lots of different avenues, from logging, throttling, using encryption (which you can't get with basic auth) etc. What is your use case for this server? What is the worst thing that could happen that you want to avoid? – AnilRedshift Feb 19 '16 at 23:07
  • @AnilRedshift I just don't want anyone to gain access to the database. My website is hidden behind a corp authentication so that is secure for sure. I'm just worried about my API being open. Although you need to have a username and password to call/curl it, I just want to be sure that my data is not vulnerable bcoz of being exposed by the API. – 90abyss Feb 19 '16 at 23:10
  • @90abyss where is api consumer physically deployed ? is it on the same machine ? – vittore Feb 19 '16 at 23:20

1 Answers1

2

Here are some risks that I see (in no particular order) along with ways to mitigate them:

Server misconfiguration

If your server has exploitable security bugs or is otherwise misconfigured, it could allow someone access to the machine, and thus your database. To prevent this, best practices include having security updates automatically applied, having a NDS, etc. etc (it sounds like you get a decent amount of protection by being behind corpnet)

Password snooping

HTTP Basic auth is sent cleartext, so theoretically anyone in your network could sniff your network traffic, steal your password, and then connect to the machine itself. Best practices here are to use HTTPS and some other protocol for authentication. The needs here come down to who you're trying to protect this information from.

API vulnerabilities

Any API provides for an input into the system, which can lead to vulnerabilities. SQL injection attacks are a common one when attacking databases. Make sure to never do raw SQL queries and take other best practices (bounds checking, etc)

Brute force attacks

Without the passsword, a malicious user could just keep trying different combinations until it finds one that successfully works. Solutions here include using strong passwords, implementing throttling and logging to detect brute force attacks. Other attacks here include leaking information (such as returning faster when more of the password is wrong, leading to faster guessing of the correct one)

TL;DR

For your use case (single user access, behind a corporate account), I think http basic auth is probably a reasonable thing to do. Your decisions should boil down to 1) How much do you trust other users on your network 2) How interesting is the data that you're trying to protect (Things like credit cards or health info etc..)

If you do not trust your corpnet to keep your data secure, or are looking for more defense-in-depth, I would consider using https to prevent sniffing the password, and then using a strong password.

AnilRedshift
  • 7,937
  • 7
  • 35
  • 59
  • This is very helpful AnilRedshift! My corpnet is EXTREMELY secure. The only thing I'm worried about is someone accessing the API directly. If a hacker tries to access my website then he won't be able to get in for sure. But supposedly he somehow tries to access my API directly (using curl and such), although he will be prompted for a username and password, I just want to be sure that there aren't ways using which he can get in by cracking the password by some hacky means. – 90abyss Feb 19 '16 at 23:39
  • I do not want to offend/abuse but claims like "won't be able to get in for sure" makes only laugh in sec. Moreover I wouldn't called network secure, if one can expose in public API (and then looking to make it secure sic!). It is better off to contact a security officer, she/he should guide you to get it done right with company policy or forbid. – kwarunek Feb 20 '16 at 16:37