Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
-
One comment from @Fast-Nop made me remember something I had promised myself not to. Specifically the USB thing.
So there I was, Lieutenant Jr at a warship (not the one my previous rants refer to), my main duties as navigation officer, and secondary (and unofficial) tech support and all-around "computer guy".
Those of you who don't know what horrors this demonic brand pertains to, I envy you. But I digress. In the ship, we had Ethernet cabling and switches, but no DHCP, no server, not a thing. My proposition was shot down by the CO within 2 minutes. Yet, we had a curious "network". As my fellow... colleagues had invented, we had something akin to token ring, but instead of tokens, we had low-rank personnel running around with USB sticks, and as for "rings", well, anyone could snatch up a USB-carrier and load his data and instructions to the "token". What on earth could go wrong with that system?
What indeed.
We got 1 USB infected with a malware from a nearby ship - I still don't know how. Said malware did the following observable actions(yes, I did some malware analysis - As I said before, I am not paid enough):
- Move the contents on any writeable media to a folder with empty (or space) name on that medium. Windows didn't show that folder, so it became "invisible" - linux/mac showed it just fine
- It created a shortcut on the root folder of said medium, right to the malware. Executing the shortcut executed the malware and opened a new window with the "hidden" folder.
Childishly simple, right? If only you knew. If only you knew the horrors, the loss of faith in humanity (which is really bad when you have access to munitions, explosives and heavy weaponry).
People executed the malware ON PURPOSE. Some actually DISABLED their AV to "access their files". I ran amok for an entire WEEK to try to keep this contained. But... I underestimated the USB-token-ring-whatever protocol's speed and the strength of a user's stupidity. PCs that I cleaned got infected AGAIN within HOURS.
I had to address the CO to order total shutdown, USB and PC turnover to me. I spent the most fun weekend cleaning 20-30 PCs and 9 USBs. What fun!
What fun, morons. Now I'll have nightmares of those days again.9 -
Me: *Installs travis*
Dev: oh what's travis?
Me: it's a continuous integration tool I wanna setup.
Dev: ... contin.... ?
Me: continuous integration, a tool that performs builds.
Dev: ah!, is it the new version of that deprecated tool we were using "client access"?
Me: ... no ... that's an authentication service that generates and stores oauth tokens. This is the continuous integration tool I told you about yesterday (and last week and the week before).
Dev: ... contin....
Me: ... con ........ continuous integration. It listens to branches on GitHub, downloads, builds, tests and then deploys the code.
Dev: ah ok ok, cool.
I would bet my monthly fucking salary he can not repeat what I said, tell me what oauth is, or explain what he's working on at the minute.
Jesus at this rate I'd bet my salary he can't tell me my name.7 -
micromanager: "Quick and easy win! Please have this done in 2-3 days to start repairing your reputation"
ticket: "Scrap this gem, and implement your own external service wrapper using the new and vastly different Slack API!"
slack: "New API? Give me bearer tokens! Don't use that legacy url crap, wth"
prev dev: "Yeah idk what a bearer token is. Have the same url instead, and try writing it down so you don't forget it?"
Slack admin: "I can't give you access to the slack integration test app, even though it's for exactly this and three others have access already, including your (micro)manager."
Slack: "You can also <a>create a new slack app</a>!" -- link logs me into slack chat instead. After searching and finding a link elsewhere: doesn't let me.
Slack admin: "You want a new test slack app instead? Sure, build it the same as before so it isn't abuseable. No? Okay, plan a presentation for it and bring security along for a meeting on Friday and I'll think about it. I'm in some planning meetings until then."
asdfjkagel.
This job is endless delays, plus getting yelled at over the endless delays.
At least I can start on the code while I wait. Can't test anything for at least a week, though. =/17 -
Fucking crunchyroll hardcodes their access tokens in a Constants Class in their APK, technically that is a security issue.
What the actual fuck Crunchyroll!? No fucking wonder you got DNS Hijacked so quick, security is literally your second priority you dumbed down twats, get some real devs and some real QAs for fucking god sakes, you're tearing down your own system by inviting exploits.8 -
me: the source code is currently store on GitHub and we use GitHub Actions after each updates to compile your code into binary before deploying to your servers
client: storing source code on GitHub (external server) is insecure and breaks compliance
me: so i guess you will need to have a copy of the source code on all your servers and build them directly there (too cheap to have a separate build server) instead of using GitHub Actions
client: yeah
me: keep in mind that all your certificates and tokens are going to be store as plain text in all your servers so if a hacker gain access to anyone of your servers, they will have access to everything.
client: yeah, this is in compliance to our security policy4 -
Devs: Hey, what should we do?
A:
provide our SDKs for download as easily as possible so that any potential customer can try it out and see how much better we are compared to our competitors?
Or…
B:
Should we lock our SDKs behind a login where the customer needs to create an account and enter the most amount of private information possible, just in case, then also require to create some security access tokens that he needs to configure in his app to have access to our service via the sdk and also hide all of the documentation behind a login which requires some permission based roles to access and also make the sdks closed source so that it’s a pain in the ass to debug and understand?
Marketing people:
B! Definitely B! Make sure to piss off and annoy our customers as much as humanly possible! -
Excerpts from "Bastard devops from hell" checklist:
- Insistently pronounce git with a soft "G" and refuse to understand people not using that pronunciation, the same goes for jithub, jitlab, jit lfs, jitkraken etc.
- Reject all pull requests not in haiku format, suggest the author needs to be more culturally open minded when offending.
- increment version numbers ONLY based on percentage code changed: Less than 1% patch increment, less than 5% minor increment, more than that major version increment.
- Cycle ALL access keys, personal tokens, connection strings etc. every month "for security reasons"
- invent and only allow usage of your own CI/CD language, for maximum reuse of course. Resist any changes to it after first draft release23 -
EoS1: This is the continuation of my previous rant, "The Ballad of The Six Witchers and The Undocumented Java Tool". Catch the first part here: https://devrant.com/rants/5009817/...
The Undocumented Java Tool, created by Those Who Came Before to fight the great battles of the past, is a swift beast. It reaches systems unknown and impacts many processes, unbeknownst even to said processes' masters. All from within it's lair, a foggy Windows Server swamp of moldy data streams and boggy flows.
One of The Six Witchers, the Wild One, scouted ahead to map the input and output data streams of the Unmapped Data Swamp. Accompanied only by his animal familiars, NetCat and WireShark.
Two others, bold and adventurous, raised their decompiling blades against the Undocumented Java Tool beast itself, to uncover it's data processing secrets.
Another of the witchers, of dark complexion and smooth speak, followed the data upstream to find where the fuck the limited excel sheets that feeds The Beast comes from, since it's handlers only know that "every other day a new one appears on this shared active directory location". WTF do people often have NPC-levels of unawareness about their own fucking jobs?!?!
The other witchers left to tend to the Burn-Rate Bonfire, for The Sprint is dark and full of terrors, and some bigwigs always manage to shoehorn their whims/unrelated stories into a otherwise lean sprint.
At the dawn of the new year, the witchers reconvened. "The Beast breathes a currency conversion API" - said The Wild One - "And it's claws and fangs strike mostly at two independent JIRA clusters, sometimes upserting issues. It uses a company-deprecated API to send emails. We're in deep shit."
"I've found The Source of Fucking Excel Sheets" - said the smooth witcher - "It is The Temple of Cash-Flow, where the priests weave the Tapestry of Transactions. Our Fucking Excel Sheets are but a snapshot of the latest updates on the balance of some billing accounts. I spoke with one of the priestesses, and she told me that The Oracle (DB) would be able to provide us with The Data directly, if we were to learn the way of the ODBC and the Query"
"We stroke at the beast" - said the bold and adventurous witchers, now deserving of the bragging rights to be called The Butchers of Jarfile - "It is actually fewer than twenty classes and modules. Most are API-drivers. And less than 40% of the code is ever even fucking used! We found fucking JIRA API tokens and URIs hard-coded. And it is all synchronous and monolithic - no wonder it takes almost 20 hours to run a single fucking excel sheet".
Together, the witchers figured out that each new billing account were morphed by The Beast into a new JIRA issue, if none was open yet for it. Transactions were used to update the outstanding balance on the issues regarding the billing accounts. The currency conversion API was used too often, and it's purpose was only to give a rough estimate of the total balance in each Jira issue in USD, since each issue could have transactions in several currencies. The Beast would consume the Excel sheet, do some cryptic transformations on it, and for each resulting line access the currency API and upsert a JIRA issue. The secrets of those transformations were still hidden from the witchers. When and why would The Beast send emails, was still a mistery.
As the Witchers Council approached an end and all were armed with knowledge and information, they decided on the next steps.
The Wild Witcher, known in every tavern in the land and by the sea, would create a connector to The Red Port of Redis, where every currency conversion is already updated by other processes and can be quickly retrieved inside the VPC. The Greenhorn Witcher is to follow him and build an offline process to update balances in JIRA issues.
The Butchers of Jarfile were to build The Juggler, an automation that should be able to receive a parquet file with an insertion plan and asynchronously update the JIRA API with scores of concurrent requests.
The Smooth Witcher, proud of his new lead, was to build The Oracle Watch, an order that would guard the Oracle (DB) at the Temple of Cash-Flow and report every qualifying transaction to parquet files in AWS S3. The Data would then be pushed to cross The Event Bridge into The Cluster of Sparks and Storms.
This Witcher Who Writes is to ride the Elephant of Hadoop into The Cluster of Sparks an Storms, to weave the signs of Map and Reduce and with speed and precision transform The Data into The Insertion Plan.
However, how exactly is The Data to be transformed is not yet known.
Will the Witchers be able to build The Data's New Path? Will they figure out the mysterious transformation? Will they discover the Undocumented Java Tool's secrets on notifying customers and aggregating data?
This story is still afoot. Only the future will tell, and I will keep you posted.6 -
Follow up to: https://devrant.com/rants/5047721/....
1- The attacker just copy pasted its JWT session token and jammed requests on the buy gift cards route
2- The endpoint returns the gift card to continue the payment process, but the gift card is already valid
3- Clients wants only to force passwords to have strong combinations
4- Talk about a FIREWALL? Only next month
5- Reduce the token expiration from 3 HOURS to 10 minutes? Implement strong passwords first
6- And then start using refresh tokens
BONUS: Clearly someone from inside that worked for them, the API and database password are the same for years. And the route isn't used directly by the application, although it exists and has rules that the attacker kows. And multiple accounts from legit users are being used, so the person clearly has access to some internal shit7 -
Hmm...recently I've seen an increase in the idea of raising security awareness at a user level...but really now , it gets me thinking , why not raise security awareness at a coding level ? Just having one guy do encryption and encoding most certainly isn't enough for an app to be considered secure . In this day an age where most apps are web based and even open source some of them , I think that first of all it should be our duty to protect the customer/consumer rather than make him protect himself . Most of everyone knows how to get user input from the UI but how many out here actually think that the normal dummy user might actually type unintentional malicious code which would break the app or give him access to something he shouldn't be allowed into ? I've seen very few developers/software architects/engineers actually take the blame for insecure code . I've seen people build apps starting on an unacceptable idea security wise and then in the end thinking of patching in filters , encryptions , encodings , tokens and days before release realise that their app is half broken because they didn't start the whole project in a more secure way for the user .
Just my two cents...we as devs should be more aware of coding in a way that makes apps more secure from and for the user rather than saying that we had some epic mythical hackers pull all the user tables that also contained unhashed unencrypted passwords by using magix . It certainly isn't magic , it's just our bad coding that lets outside code interact with our own code . -
I've been using the Square REST API and I spent one hour thinking there was something wrong in my code until I f** found that THEY were not following OAuth 2 guidelines, which made their workflow incompatible with the OAuth lib I was using, so I had to mark an exception for Square's OAuth from the rest of my OAuths. Specifically, RFC 6749 Section 4.2.2 and 5.1.
However, after reading OAuth 2 guidelines, I became angry at THEM instead. The parameter `expires_in` should be the "lifetime in seconds" after the response. This will always be innevitably inaccurate, since we are not taking into account the latency of the response. This is, however, not a huge problem, since the shortest token lifetimes are of an hour (like f** Microsoft Active Directory, who my cron jobs have to check every ten minutes for new access tokens). Many workflows (like Microsoft, Square, and Python's oauthlib) have opted to add the `expires_at` parameter to be more precise, which marks the time in UTC. However, there's no convention about this. oauthlib and Microsoft send the time in Unix seconds, but Square does this in ISO 8601. At this point, ISO 8601 is less ambigious. Sending a raw integer seems ambiguous. For example, JavaScript interprets integer time as Unix _milliseconds_, but Python's time library interprets it as _seconds_. It's just a matter of convention, a convention that is not there yet.
Hope this all gets solved in OAuth 2.1 pleeeaasseee
1 -
PM asked me to develop an application to fetch data from the customer's DB, which would require an access security token provided by the customer. To get the token, I would have to travel to Germany (I live in Portugal) to get it personally (it's not possible to have someone else pick it up for me).
It turns out the security token is a completely closed environment, with its own OS, without the possibility of installing any application or communicating with the exterior. The laptop itself would boot from the token's OS.
It was concluded I would have to hack the security token, which is completely non compliant. So the PM decided not to go forward with it.
But now, I have to go Germany anyway to pick up the security tokens because they forgot to order them for these other guys who would be using them to access the customer's DB manually and they don't want to delay the project anymore.
Oh, and the security tokens cost the project 500€/month each...3 -
Security is a joke. And people don't seem to get it. Especially Data mungers.
I've spent about half an hour trying to work out how to securely connect to power BI using PowerShell in a renewable manner for unattended access later on.
Every single example I've found seems to involve you storing $user and $password variables inside your script. If I'm lucky, they're going to pass them through ConvertTo-SecureString. And nobody talks about securely storing AD auth tokens, or using the Windows Credential Manager.
I know it's possible, but it's going to take me ages to work out how from all sorts of disparate sources...16 -
fuck it, im giving my users permanent access tokens, because for some reason using refresh tokens is black magic to the internet -.-7
-
Creating the build script for the CI pipeline:
- 20% trying to avoid someone getting access to passwords, tokens, etc.
- 10% writing commands for the build and tests
- 70% writing work arounds for bugs and errors caused by the CI system or SDKs in headless environments...4 -
What is the reason behind Git Access Tokens being viewable only once after generation on platforms like GitHub? I'm struggling to comprehend this approach as it compels me to store the key in an insecure manner.3
Top Tags
Weekly Rant
View