I recently moved some of my repositories from AWS Code Commit to GitHub. I accidentally made one of the repositories public, instead of private. Within less than 10 mins of committing the code, I got an email from Stripe that my secret key is publicly accessible, and it included the exact file/code line which has the key.
How did this happen?
Does GitHub detects existence of some sensitive info and informs the provider via some WebHook?
Does Stripe keeps crawling new repositories for such leakages? It sounds practically impossible to detect so quickly.
I cannot get my head around what could have triggered this detection at Stripe's end. I was thrilling to see the action though. Of course I have rotated the secret key.
Related
We had a developer submit a PR that had a plain text password in it. The reviewer asked it to be removed and loaded in another way so it didn't make its way into the repo. It has since been fixed. However, the history of the PR still shows the original commit with the password. Is there any way to remove a portion of the history of the PR (or if necessary the entire PR) so that other users cannot view that password?
If there isn't a supported answer, we happen to be using AzDev 2019 server, which I believe should enable us to remove it somehow...
Note in this case we can just change the password, so this isn't a deal-breaker, but it would be nice to know how to do this for future occurrences where changing a password is more difficult.
It's not able to delete a Pull Request at the moment in Azure DevOps Sever.
We already have a user voice in Develop Community feature request site. Kindly vote up and track the status.
Allow deletion of pull requests
https://developercommunityapi.westus.cloudapp.azure.com/idea/365572/allow-deletion-of-pull-requests.html
If you hadn't commit the pull request, we give an option to abandon the pull request which leaves them hanging around.
This should be a team process policy to avoid users commit plain-text password. Changing the password, that's the safest option.
I see your point but the rule of thumb is - if password was exposed you should revoke it asap.
You can also try this:
To replace all text listed in passwords.txt wherever it can be found
in your repository's history, run:
$ bfg --replace-text passwords.txt
I was looking at REST API for Pull requests, but there is nothing about removing it.
I have encountered a similar problem and one solution could be to remove the repository in Azure which would remove the history as well. So fixing the issues locally then creating a new remote repo for the branch would be a way to go.
I'm transitioning a Google Docs add-on that was approved when the add-on concept first started (many years ago) from a Docs-only add-on to one that works for both Slides and Docs. In the process, I have had to redefine a lot of things (create a new project) and request authorization for OAuth scopes.
I had assumed that if my add-on had ../auth/documents.currentonly (which is truly all it needs), then I was good to go. I did have to request authorization for external_service and container.ui, which I obtained quickly from Google. So, I published the add-on, and all looked OK. I was able to install it on my test accounts, etc. I've seen the number of public users go from 0 to 63 in about a week.
However, I just got an obscure email from Google saying I had to take action because I didn't have the authorizations:
Apps requesting risky OAuth scopes that have not completed the OAuth developer verification process are limited to 100 new user grants.
The email doesn't specify what scope is risky, however. The OAuth consent screen shows all my APIs that needed authorization are approved (I also have an email showing they were granted authorization):
The consent screen doesn't allow me to request verification (the button is grayed) in its current state. I assume that, since no verification is requested or given for them, the currentonly scopes are not "risky".
I have replied to Google's email (which seems to be automated), and will hopefully get some more info.
In the meantime, I wondered if perhaps I misunderstood the scopes. It was a complex process and I don't remember if ../auth/documents.currentonly was automatically added to the screen, or if I had to add it at some point. I know it comes from a comment in the code of the add-on:
/**
* #OnlyCurrentDoc
*/
This is explained on https://developers.google.com/apps-script/guides/services/authorization
I'm wondering if the problem is that since my add-on is published, I also need to explicitly add a broader scope: ../auth/documents, which is indeed a scope that requires authorization ("risky"?). My add-on doesn't use other documents than the current one, so that wouldn't make sense to need it. It's how I understood the Google documentation about this.
As an experiment, here's what the screen looks like if I add that scope:
If I add that (and the corresponding one for presentations), I can request another verification (although I am unsure if it's really needed). Do the currentonly scopes also require the broader ones?
Update 2019-12-13
Today, even though I still have no reply to my response to the automated email, I see that my add-on has more than 100 users. That should not have happened according to the email I received, unless something changed. I'm assuming someone resolved the inconsistency on the Google side of things.
I have Travis-ci on a public repository. After finishing the execution it generates a image that I want to upload to cloudinary.com, but it could be any other service.
The problem is that to do it, I need to add in .travis.yml the auth token. But I don't want to expose it publicly, and for that travis offers a way to secure Env variables: http://docs.travis-ci.com/user/environment-variables/#Secure-Variables. However they do not work on PULL requests:
Secure Env variables are not available on pull requests from forks due
to security risk of exposing such information to unknown code.
Encryption and decryption keys are tied to the repository. If you fork
a project and add it to Travis CI, it will have different keys to the
original.
Anyone has any idea about how could I add an hidden value that is available for PUSH and PULL REQUESTS?
As you already wrote in your question: according to the official Travis CI documentation https://docs.travis-ci.com/user/environment-variables you won't have access to these variables from untrusted builds such as pull requests. This makes sense, since someone could submit a pull request to your repository containing malicious code which then exposes your secret value.
Bottom line: if you want to make secret values available to pull requests, you have to assume they're not secret anymore - therefore you could also just hard code the unencrypted value to your .travis.yml and use it from there. Which doesn't seem like a good idea. ;-)
Possible solution in your case: you could just use an image hoster which provides anonymous uploading? You wouldn't need an auth key, so your pull requests would be able to upload, too.
SagePay's form callback can be hacked by re-using the success URL that the user is directed to upon a successful transaction. This can create all sorts of problems with duplicate transactions, fake transactions etc.
You can check for a duplicate VPSTxId, but these can be generated anew by hacking around the crypt parameter of the callback URL.
The crypt parameter can also be manipulated to generate a different "Amount" field.
I have not tested what other field values can be changed by hacking the callback URL crypt parameter.
Is there any way (as per PayPal's IPN validation) of doing a double-check callback to SagePay to ensure that the transaction is new and unique?
Thanks for your post. In general we encourage clients to use Server integration where they can. We also constantly monitor transactions for suspicious behaviour and proactively contact our customers if we suspect any malicious activity.
We recommend customers make sure that they’re using the latest version of our integration protocol which is currently v3. Get the latest integration documents.
As Dan suggests you could use the Reporting and Admin API to validate that a transaction does indeed exist on the Sage Pay side but having an additional validation mechanism (like PayPal's IPN) is something we will actively explore.
If you'd like us to update you on this, then please get in contact with our customer services team at support#sagepay.com or 0845 111 44 55.
Sage Pay Support
You should always redirect a user from a success URL.
I personally use a fulfil page (success url), and a thank you page. On the fulfil page, you should obviously only ever process a transaction once (based on the transaction id), and you can store crypt sent with a transaction. The crypt will have to be valid and is only possible to encrypt if you have the encryption key.
So hacking would be extremely difficult unless you are being very security lax, and the hacker would have to know your encryption key to even begin trying to hack it.
Alternatively, you should use the server integration, so that the communications are server-server, not client-server. There is little difference between form and server.
10 immutable laws of security
http://technet.microsoft.com/library/cc722487.aspx
Is there a way to protect oneself from Mercurial identity theft?
The case is if someone deliberately commit bugs into the code using another developer's name with the goal of getting that person fired or mis-credited.
Is there a way to stop that from happening or is it a non issue?
I don't know a way to actually restrict the commits not so include a "stolen" identity, but if you have a centralized repository you should be able to securely audit who has pushed which changes to the server, and thereby track down the identity thief.
Edit: there seems to be support for signing commits with two extensions, the CommitsigsExtension as well as the seemingly less secure approach implemented by the GpgExtension.
Signing the changesets effectively prevents identity theft since the thief does not have the private key of the identity he wants to steal, thereby he cannot sign the commit.
The Mozilla project does this in the form of a pushlog. They made a trivial change to the web templates to show the output of a pushlog which is easily created at push time using a changeset hook. Here's what their log looks like:
http://hg.mozilla.org/mozilla-central/pushloghtml
A hook that creates such a log could be as easy as:
[hooks]
changeset = echo $REMOTE_USER pushed HG_NODE >> /path/to/my/pushlog
In practice this is one of those things that everything thinks will be a problem when they first hear that the "user" field is entirely falsifiable, but in practice is just never actually a problem.
Use access control on the "main" repo and log requests. If you log who authenticated to push each commit, you can tell who really pushed a particular commit, regardless if the info in the repository.