Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Caffeine – Minimum viable back end for prototyping

github.com

Post reply on HN
Print view View original

51–60 of 83 posts

Re: Show HN: Caffeine – Minimum viable back end for prototyping

#51

Post by robmccoll »

mahogany wrote: post #49
grey-area wrote: post #40

Earlier quoted context omitted.

Yes, don't do this: https://github.com/rehacktive/caffeine/blob/master/database/... "INSERT INTO %v (id, data) VALUES('%v','%v') ON CONFLICT (id) DO UPDATE SET data = '%v'" Use prepared statements and parameters passed to the db driver, not building strings with strings or you are vulnerable to sqli. I'd also avoid using %v anyway when building strings - safer to use a specific type like %d for int.

Are you saying that %v should be avoided in general, or just in the context of queries? (Go noob who doesn't understand %v)

In queries, you should use the database/sql.DB interface if possible with your database https://pkg.go.dev/database/sql#DB.Exec

It should sanitize / quote arguments for you and protect against SQL injection. Note that this doesn't mean all data sanitization is performed, just the basic '; do my stuff here; -- type of things.

Re: Show HN: Caffeine – Minimum viable back end for prototyping

#52

Post by grey-area »

mahogany wrote: post #49
grey-area wrote: post #40

Earlier quoted context omitted.

Yes, don't do this: https://github.com/rehacktive/caffeine/blob/master/database/... "INSERT INTO %v (id, data) VALUES('%v','%v') ON CONFLICT (id) DO UPDATE SET data = '%v'" Use prepared statements and parameters passed to the db driver, not building strings with strings or you are vulnerable to sqli. I'd also avoid using %v anyway when building strings - safer to use a specific type like %d for int.

Are you saying that %v should be avoided in general, or just in the context of queries? (Go noob who doesn't understand %v)

First, don't build strings like this for sql.

But for other strings built with sprintf, yes I am saying don't use %v unless for debugging, it's just one more avenue where you might be surprised by input, even if you're not building strings for sql. For example, someone might do this with user supplied data:

myoutput := fmt.Sprintf("user:%v",userID)

and if userID is a string like "foo" it'll end up in their string and they won't get what they expect. So better to just put another guardrail on there and insist that the param is an integer or whatever you expect by using %d which will only accept an int - this means you have to convert it to an integer first.

Many vulnerabilities are caused by data not being in the format people expect (not just sqli).

Re: Show HN: Caffeine – Minimum viable back end for prototyping

#53

Post by cozzyd »

thih9 wrote: post #20

FYI, there is a name clash with Caffeine, a Mac OS menu bar app that keeps the screen awake: https://intelliscapesolutions.com/apps/caffeine . But I guess this is expected with a name like this, and the scopes of the projects are clearly different, so this should be relatively harmless.

And a gnome shell extension that does the same thing.

Re: Show HN: Caffeine – Minimum viable back end for prototyping

#54

Post by btbuildem »

gwbas1c wrote: post #45

At a minimum, this should be password protected by default. One of the security lessons from the late 1990s and early 2000s is that things like this quickly get hacked. Many developers forget that a service where all security is handled client-side are easy targets for hacking. Furthermore: In a lot of cases, people will ship prototypes and run their stuff on top of them long after they have outgrown a critical compo…

Pretty sure this is meant for prototyping and maybe demoing in controlled environments.

As soon as you involve auth, things get boring and annoying.

Re: Show HN: Caffeine – Minimum viable back end for prototyping

#55

Post by throw_m239339 »

johnday wrote: post #42
grey-area wrote: post #40

Earlier quoted context omitted.

Yes, don't do this: https://github.com/rehacktive/caffeine/blob/master/database/... "INSERT INTO %v (id, data) VALUES('%v','%v') ON CONFLICT (id) DO UPDATE SET data = '%v'" Use prepared statements and parameters passed to the db driver, not building strings with strings or you are vulnerable to sqli. I'd also avoid using %v anyway when building strings - safer to use a specific type like %d for int.

You're right of course, but I think the idea of this software is that the user (and, by extension, their input) are trusted.

> You're right of course, but I think the idea of this software is that the user (and, by extension, their input) are trusted.

No, you should enforce the most basic security practices even if the users are "trusted". Somebody might put that on the internet for a demo for client and get hacked in no time, because the code is opened to SQL injection. This isn't acceptable. There are minimum security standards every project should follow.

And since none of the minimum security standards are implemented in that project, I would not recommend using it until they are.

Re: Show HN: Caffeine – Minimum viable back end for prototyping

#56

Post by [deleted] »

IggleSniggle wrote: post #38
enstyled wrote: post #18

Earlier quoted context omitted.

Parse is still around and supported: https://github.com/parse-community/parse-server

This is bizarre. I spent a good 5+ min looking over the README and documentation site, and couldn’t find out what that project is other than “a backend that runs on Nodejs.” Yeah ok but what is it? Why am I interested? I’m not looking to be sold, just for it to tell me what it’s for. I have some assumptions based on how I got linked there, but this is surprising to me.

[deleted]

Re: Show HN: Caffeine – Minimum viable back end for prototyping

#57

Post by throw_m239339 »

btbuildem wrote: post #54
gwbas1c wrote: post #45

At a minimum, this should be password protected by default. One of the security lessons from the late 1990s and early 2000s is that things like this quickly get hacked. Many developers forget that a service where all security is handled client-side are easy targets for hacking. Furthermore: In a lot of cases, people will ship prototypes and run their stuff on top of them long after they have outgrown a critical compo…

Pretty sure this is meant for prototyping and maybe demoing in controlled environments. As soon as you involve auth, things get boring and annoying.

> As soon as you involve auth, things get boring and annoying.

No, JWT is easy enough to implement.

Re: Show HN: Caffeine – Minimum viable back end for prototyping

#58

Post by Cthulhu_ »

aw4y wrote: post #43
grey-area wrote: post #40

Earlier quoted context omitted.

Yes, don't do this: https://github.com/rehacktive/caffeine/blob/master/database/... "INSERT INTO %v (id, data) VALUES('%v','%v') ON CONFLICT (id) DO UPDATE SET data = '%v'" Use prepared statements and parameters passed to the db driver, not building strings with strings or you are vulnerable to sqli. I'd also avoid using %v anyway when building strings - safer to use a specific type like %d for int.

the reason I went "quick'n dirty" is for the prototyping nature of the project. But I'll fix this anyway, thanks!

There's nothing as permanent as a temporary solution. There's been countless SQL injection vulnerabilities exploited over the past decades with the "I'll fix it later" mindset.

Start with prepared statements by default, they are not more work than formatting strings.

Re: Show HN: Caffeine – Minimum viable back end for prototyping

#60

Post by gwbas1c »

btbuildem wrote: post #54
gwbas1c wrote: post #45

At a minimum, this should be password protected by default. One of the security lessons from the late 1990s and early 2000s is that things like this quickly get hacked. Many developers forget that a service where all security is handled client-side are easy targets for hacking. Furthermore: In a lot of cases, people will ship prototypes and run their stuff on top of them long after they have outgrown a critical compo…

Pretty sure this is meant for prototyping and maybe demoing in controlled environments. As soon as you involve auth, things get boring and annoying.

Honestly, anything simple. It could be as brain-dead simple as passing a password on the command-line, and then requiring the password as a header.
Post reply on HN