Category: Quickies

Do you use curl? Stop using -u. Please use .netrc

2017-March-21

An unsolicited tech tip.

Those of you who are API people, should exhibit good API hygiene.

One aspect of that is: “stop using curl -u” !!

Sometimes you have the urge to run a command like this:
curl -X POST -v -u 'yourusername:password' . https://foobar/slksls

Avoid this.

OK, ok, I know sometimes it’s necessary. But if you have an API endpoint that you often tickle with curl, and it accepts credentials via HTTP basic auth, you should be using .netrc to store the credentials.

The problem with using -u is that the password is shown in clear text on your terminal!

OK, I know, you’re thinking: but I’m the only one looking at my screen. . I can hear you thinking that right now. And that may be true, most of the time. But sometimes it’s not.

Sometimes you cut/paste terminal sessions into an email, or a blog post, or a bug report. And that’s when your password gets written down and shared with the world.

Treat Basic Authorization headers the same as passwords, because any observer can easily extract your password from that.

You might think that it’s ok to insert credentials in an email if it’s just being shared among your close work colleages. But that’s a bad idea also. Audit trails depend on the privacy of credentials. If you share them, the audit is gone. Suppose you have a disgruntled (ungruntled? never gruntled?) colleague who decides to take your creds and use them to recursively curl -X DELETE a whole bunch of resources. And the audit trail will show YOUR name on that act.

In short, it’s bad form. It could be forwarded or copy/pastad or it could leak into habit. It sets a terrible example for the children.

Here’s what I suggest:

Option 1: if you use curl

If you have a *nixy machine, create a ~/.netrc file and insert your creds there. See here for information.

chmod the file to 400. When you use the -n option, curl knows how to extract your creds from the file silently. You never have to type credentials on the command line again. I think you can do this on Windows too, but I don’t know curl on Windows.

If you build scripts that use curl, you should allow the user that same option. That way the user never keys in their creds to your script.

When you pass the -n option to curl, instead of -u USER:PASS, it tells curl, “if you ever connect with site.example.com, then use THESE creds” . This works with any HTTP endpoint curl can address via Basic Auth. I have creds for Jira, Heroku, and other systems all in my .netrc.

Hint: also don’t use curl -v, because that will show the basic auth header. You probably want -i anyway, which is less verbose than -v.

Option 2: don’t use curl

Use some other tool that hides the credentials completely.
I think Postman doesn’t quite hide the creds completely. So be careful!

Let’s all try to exemplify good security behavior.

Mac OSX users: update openssl. Also: openssl built-in to Mac OSX is different than brew version

2016-January-28

If you use openssl on Mac OSX to maintain certs, etc, you should keep it up-to-date.

Worth knowing, courtesy of a comment by Gordon Davisson on THIS Stackoverflow question

…the major problem isn’t the openssl command, it’s the openssl libraries (which are used by other programs) — those aren’t API compatible between versions 0.9.x and 1.0.x, so you do not want to update the system-supplied openssl libraries!

Here’s how you get the latest openssl from brew. First, make sure you have brew installed and updated (per brew.sh):

If you already have brew installed, the output of that command will tell you.

OK, at this point you have brew installed. Then, update brew and update openssl:

If your brew is somehow broken, this command will give you lame messages. To fix, you can try “brew doctor”. (Once I resorted to simply re-installing brew. I ran the “brew install” command, which said “brew is already installed”, and then told me how to uninstall. I uninstalled, then ran the brew install again.)

Be aware that /usr/bin will probably be first on your path, so if you want to use the latest openssl you will have to explicitly request it with the fully qualified path name.

And also be aware that brew does not yet have openssl v1.0.2f, which includes the fix for CVE-2016-0701.

The spec formerly known as Swagger is now OpenAPI

2016-January-25
headline

Swagger has been renamed! Three weeks ago. I didn’t realize this, and (forgive me) I’ve been continuing to use the term “swagger” when I really should have been using “OpenAPI”, in the time since.

OAI Logo

Helpfully, Marsh, an esteemed colleague of mine, has produced a slackbot to remind me to use the world “OpenAPI” every time I type the… uh… old word… in slack chats. Now, I just need that slackbot to follow me around and remind me every time I *say* the old word.

There’s a new group, the OpenAPI Initiative, whose members include IBM, Google, Apigee, Intuit, Microsoft, Paypal… these members will govern the evolution of the spec.

REST Assured (hahahaha! ya get it?) that Apigee will be building some nice innovations on top of the OpenAPI spec. Exciting things coming soon. You can already see the beginnings at apistudio.io.

Apigee_API_Studio

It’s not difficult to imagine some interesting possible paths forward, from that tooling.

And, omigosh, I just realized that I haven’t posted an article here in about 6 months! Wow I must have been busy…

Chrysler is Internet-enabling your car as a way to accelerate death

2015-July-21

From the holy-shit-how-did-they-not-test-this department, Fox News tells us that it is possible for hackers to seize control of a moving Chrysler automobile, fiddle with the radio, turning on the windshield wipers, or more ominously, controlling the transmission and the brakes. Considering the source (Fox Newsertainment), I am unsure whether to believe this. But there is also a piece on Wired. If true, seriously, Holy Shit.

Yes, APIs are everywhere.

Here’s an idea for the API team at Chrysler that has made the driveline remotely programmable – you guys should talk to the security team at Chrysler.

Update:Chrysler is recalling 1.4 million cars over this.

Sane names for screenshots on Mac OSX

2015-July-9

Back when I was a Windows user and a .NET developer, I used a tool called Cropper to grab screen shots. That tool is great alone, and there are plugins for various photo destinations. I wrote and maintained a few plugins.

The basic capability to grab a portion of the screen into an image file is built-in to OSX, which is nice. I learned about it here.

I use the Command + Option + 4 sequence daily to grab interesting bits of the screen, for bug reports, demonstrations, illustrations, sharing information with friends, posting to Twitter, and so on.

But I miss the flexibility of Cropper. In particular, WTF is with the filenames, OSX?

OS X saves each screenshot with the name Screen shot [date] at [time]. As an example, a screenshot taken on July 9th, at 7:21 AM will be saved as Screen shot 2015–07–09 at 7:21 AM.png

Ugly! Lots of people ask how to change the filenames, and the standard answer isn’t quite satisfactory for most people. I use the terminal often, in addition to dired mode in emacs; because I fiddle around with files and directories outside of Finder, I’d like filenames that:

  • allow lexicographic sort order to also deliver a time-based sort
  • do not include spaces in the name

Not so much to ask, eh?

But the basic options to configure the names of the files are really poor. Basically I can move around the date and time portions of the file name, but I cannot change their formats to something more like ISO-8601, which is sortable. I don’t need strict ISO-8601, I just want something sortable.

The way I did it: I created a script that runs periodically, via launchd, checks for screenshot files with the ugly names in the Desktop folder, and then renames them appropriately.

You need 2 files to make this happen. One is the plist for the LaunchAgent. Create a file in /Users/YOURSELF/Library/LaunchAgents, I called mine local.screenshot.fixup.plist. The contents should look like this:

The second is the bash script that renames the files. Put this file anywhere (but you must reference that location as the Program string in the plist file above), and chmod it to be executable. The contents are like this:

After creating these files, you can either:

  • logout and log back in…
  • OR, run this command from the terminal:
    launchctl load ~/Library/LaunchAgents/local.screenshot.fixup.plist

… in order to get the new launchd to start renaming files.

When the screenshot is initially saved, it will have the original ugly name. But in one or two seconds, the watcher will run, find your screenshot file, and rename it.

Nice.

More info:

Keyless Entry Systems are really Theft-assistance systems

2015-April-15

Bright-eyed Toyota product planner: “Hey, wouldn’t it be great if we could have the car open automatically, when the owner of the car walks up to it?”

Naive Toyota Engineer: “Yeah! Let’s make a Passive Keyless Entry and Start (PKES) system. The car will call out to the key and will open up if it finds the key.”

Skeptical pointy-haired boss: “Whoa – it sounds like this could be a security problem. What if I’m 20 feet away from my car, around the corner? Will some shady character be able to pull the door handle and gain entry?”

Naive Toyota Engineer: “No worries! We’ll make the radio communication work from only a few feet away. The key will HAVE TO BE right next to the car.”

All: “OK, good plan!”

NYTimes article on an interesting and potentially very expensive vulnerability in systems that allow keyless entry to automobiles. This “innovation” allows you to simply walk up to your car with the key in your pocket, and pull the door handle, to get the car to unlock for you.

How does it work? On the handle pull, the car attempts to contact the key wirelessly, and upon getting a valid response, unlocks. What could possibly go wrong?

Thieves are using simple power amplifiers to extend the distance over which this communication works, so they can open the car in the driveway at night, just by pulling on the handle, while your key is by your bedside. Not only do they gain entry to your vehicle and its contents, they can also start the car, and drive off. The engine won’t stop even if the key goes out of range.

I wonder if Toyota have a software mechanism to turn off this capability. The NYTimes article suggests putting the key in a Faraday cage, like your freezer.

Interesting in-depth analysis of the vulnerability, from 2011, here.

Disclaimer: I don’t drive a Prius. Also I don’t work for Toyota, but I think their vehicles are pretty good, generally. I guess there are other automobile makes that have similar vulnerabilities.

Moving to nearlyfreespeech.net – bare domain and www

2014-June-13
NFS

I moved to nearlyfreespeech.net this week, from 000webhost.com. It is much faster, and now I won’t get popup ads.

While moving the site, I took the opportunity to upgrade to the current WordPress. I think I was on WP3.3 previously; now it’s on the current release. And now I’m on the current PHP, too. Nice.

Everything went pretty well. I had some fun with the wordpress part – updating the existing plugins, using wp-cli, fiddling around with my own plugins which had a few problems using deprecated WordPress functions…, doing surgery on other plugins, now abandoned.

I had to update from the old Twitter widget I had been using; it was still using the Twitter v1 API, which did not use OAuth. This API is no longer supported, so the widget wasn’t able to retrieve any tweets. I found a new one called… really-simple-twitter-feed-widget. And it was pretty simple, in the end. But I did have a problem: when pasting my token secret into the configuration box, I inadvertently had grabbed a leading space. Instead of pasting “XYZABC” as the token, I had pasted “_XYZABC”. But I didn’t realize this, because the textbox was masked, and all I saw was those dots.

The incorrect token secret caused all of the signatures generated by the widget to be invalid; therefore the Twitter API was rejecting them. I had to crack into *that* code as well, to diagnose this. Only printing out the token secret just before it was used to generate the OAuth1.0a signature showed me the light. After that, the new Twitter widget just worked! Sweet!

Finally, I got all the PHP squared away.

NFS is a cheap hoster, but easy? No. I don’t mind the lack of cPanel. I love the SSH access to my machine. Everything is possible on NFS; the trick is figuring out HOW to do stuff.

The last thing I got stuck on, in the move to NFS, was configuring http://dinochiesa.net to redirect to www.dinochiesa.net. The FAQ for NFS says that you can do it using “a hard canonical name”. But doesn’t say HOW to make that effective. Back and forth through the FAQ on the NFS site, to no avail.

At last, this blog post helped me.

  1. Go to the Nearlyfreespeech UI ->Site->Select the site in question->Add a new alias e.g. dinochiesa.net
  2. Once dinochiesa.net appears under the Site Name and Aliases table in the site menu, click the “Set Canonical Name” (on the menu on the right)
  3. Select HARD Canonical settings and select www.dinochiesa.net

Thanks, Keith! I don’t know why this isn’t in the FAQ doc for NFS.