We use Cloud SDK in our project to make connection S4Hana service from SCP.
As a result we use destination service where we configure the destination where we want to connect to.
During this we observed that the Destination service credentials were logged when the log level was set to DEBUG. It contains all the information about the client id ,client secret, tokenServicePassword etc fields without even encrypted format.
Is there any reason for logging the password or is it a miss.
The class ScpCfDestinationLoader has a private method queryDestinationService that indeed does log the response payload of an internal request to the Cloud Foundry Destination Service, with log level DEBUG. It's clear that for debugging customer/consumer issues, such responses give very important hints on unexpected situations and potential user misconfigurations. It needs to be logged somewhere, otherwise time-intensive remote-debugging sessions would be necessary to investigate every error.
With the default configuration of your Cloud Foundry account, no debug messages are logged. If you (as administrator) decided to enable DEBUG messages, then you should be aware that potentially sensitive information will be stored in the log files. Who can access the log files, can be controlled by the account administrator.
We already took some precautious steps to hide sensitive information from being extracted when dealing with Destination instances. The overly "talkative" log messages, that you are referring to, will definitely be subject to further adjustments as well. Thanks for pointing it out. In the future we will stop credentials (password / client secret) from being written to debug log here.
However, we consider debug log messages as not-production relevant.
Please note: The same situation does not only apply to Cloud SDK but also the underlying Apache HTTP framework, e.g. the classes of its Wire package. Here every byte of internal HTTP traffic is logged in detail. If a potential attacker has full access to logs of a Java application, he pretty much sees every network activity.
Related
I have been trying for quite some time to develop an authentication system using firebase/auth, however this has yielded unsatisfactory results and I have noticed then whenever I log a user in the website, then I access the website from another device I can see all the data of the previous user, without needing to logIn at all. I have researched online on how to solve this however even after having done everything the firebase docs are saying, I still encounter the same problem. I can't leave it like this since it is of course a HUGE security risk. So I took the matters to my own hands and created an authentication system with json-web-tokens, this works very well, however due to my configurations of the firebase storage security rules It is impossible for me to access the data since I am not logged in with firebase/auth.
I have done my best not to show any links or configuration to my account in firebase, all images are fetched and converted to base64 in the server-side then later rendered on the page, so if I keep my firebase configurations hidden and I dont show any firebase storage links on my website is it safe for me to allow read and write without checking for the user to have been logged in using firebase/auth
rules_version = '2';
service firebase.storage {
match /b/{bucket}/o {
match /{allPaths=**} {
allow read, write: if request.auth != null;
}
}
}
If all access to the files in Cloud Storage comes from the Node.js SDK, it bypasses the security rules that you set anyway. So in that case, you might as well disallow all access:
allow read, write: if false;
Yes, this can be very dangerous.
To find your configuration is easily done, since they need to be public for your connection to even work on your frontend.
If someone wants to find your config, they can. This is why security rules are very important and you should not allow everyone to access your database.
Based on your current security rules:
If someone gain access of your config, They can simply register an account and then delete your entire database with a few lines of code
If you only communicate with Firebase via a service account on a server. i.e. you are not using the web SDK, you can disable it like this:
Go to Firebase console > Project settings > General
At the bottom of the page you will see your active web apps.
Select the on you want to disable and choose Remove this app
Now noone can access your app via the web SDK
I had a node app hosted as an azure web app on Linux environment. The node service handles events requests as a GET method. The application was working fine and all of a sudden since last 2 days it started throwing 431 error.
there was another similar question posted link but this is not the case here. I do not have AAD enabled
have also verified below areas
no change in the node app
no change on the client side sending the get request
no explicit headers are sent. this was verified by making simple postman calls as well
what could have gone wrong here? any help?
Is it only happening for certain users? When I've seen this in the past, it was because we kept user role & state in the token (which generally does get passed in a header) and for some "test" users that had access to absolutely everything, that token was too large and we had a 431. For pretty much any other user things were fine.
Our fix was to use a key-value store (could be SQL, CosmosDB, etc.) and the user token was now an ID that mapped to the value in the data store, and the role & state info was moved there.
I've built an API-based integration with DocuSign (using their PHP SDK), and am now at the point of deploying to the production server. I have reconfigured everything with the production integration key, public/private key pair, user and account IDs, endpoint URL, etc. replacing the demo ones. The OAuth portion of the conversation is working fine, and I get a valid token back. When I then try to send an envelope, I hit a USER_LACKS_MEMBERSHIP error, and cannot figure out why. As far as I can see, everything about the API user is the same between the demo and production systems.
I've authorized the application and made sure that it's in the list of "Applications with Access to DocuSign".
I have enabled logging, but the only things that are showing up in there appear to be from my own navigation in the site, nothing related to the API calls at all.
Most of the documentation that I can find on this simply repeats the generic error text: "The UserID does not have a valid membership in this Account." If I go to the account admin and look at the list of users, the one I'm expecting is right there, with DS Admin permission; not sure what else might be done to give them "membership". One mentioned not using SendOnBehalfOf, but I'm not, so I can't really remove that.
All the code is identical, just configuration that's changed. Not sure where else to look. Anybody have any suggestions for what to try?
FURTHER INFORMATION
I've tried the getUserInfo call in the SDK, passing the same access token I use for the other call. It returns successfully, showing that it is for the user I'm expecting, in the one group we have, on the production server. And yet, when I enable logging again, as this same user, there is still zero record in the resulting logs of any of this API activity.
Attempts to do things like list templates with the SDK fail with the same USER_LACKS_MEMBERSHIP error.
Using the Diagnostics API (again, through the SDK) to check logging status shows that it is NOT enabled (despite my enabling it in the UI), but can be enabled with a separate call. Subsequently attempting to use listRequestLogs in the SDK generates a 404 error, though the URL matches what's listed in the API documentation (/v2/diagnostics/request_logs). Not sure whether these findings confirm that I'm somehow logging onto the API and the UI with different users (even though the user name and internal ID match), or that there's some problem with the logging facility in DocuSign.
The problem turns out to be the URL I was using for API calls. I switched from demo.docusign.net in testing to www.docusign.net in live, but being in Canada we need to use ca.docusign.net. For those who find this later, you can get the correct base path to use from the oauth/userinfo endpoint, or the getUserInfo() call through the SDK (PHP SDK, at least; don't know what the analogous call would be in others).
There are 3 things to consider:
API calls are made to an endpoint (URL) that contains the account # (either GUID or short form) in the url. Take a note of that number in the url.
Auth Token is a token for a specific user in a specific account.
UserId for the specific call. That is a specific user in the account.
If the user is not in the account, or there's a mismatch between #1 and #2 - you'll get this error. You must work with a single account and have it in all places as well as the user must be a member of this account.
Re:
I have enabled logging, but the only things that are showing up in there appear to be from my own navigation in the site, nothing related to the API calls at all.
Since the request logging is not showing your API activity, the problem is that the person you've logged in as on the web tool is not the same as the person (user id) that you've logged in as on your application.
Solution for OAuth Authorization Code authentication: double check that when your app is logging into DocuSign, you're using the account.docusign.com authentication server, not the account-d.docusign.com auth server. (Look at the URL in your browser during the login sequence.)
Solution for OAuth JWT authentication: re-check that the impersonated user id is from the production system and you're using the right authentication server
I am trying out the Azure AD-B2C. The user signup/sign in is fine when the MFA is turned off. But when I turn it on, and the user tries to sign in and provides the phone number, and requests a text message by clicking "send code", I get the Http 400 error: size of request headers is too long. Anybody else have this issue?
The error HTTP 400: Size of header request is too long generally happens because there's too many cookies.
Azure AD B2C's login goes through login.microsoftonline.com, as does almost every Microsoft service (O365, Azure, etc). So if you've got several accounts that you've signed in to across these services, you're accumulating cookies that will cause this problem.
Clearing the cookies should resolve this problem. If this is happening on a recurring basis, you should edit your question to include details about the request and cookies in order to best figure out what's bloating the request and how to reduce it.
Short answer: The file with the custom UI was not found by Microsoft login service. After getting shipped around it resulted in the error.
I had the same error with AAD B2C but "cookies" was not the problem. In my case I got the error while testing in the Azure B2C portal checking the policies and the custom UI pages. We use Azure Blob storage to hold custom login setup, its fast and it scales without our attention. The problem was found by using my test website using the B2C service. I put a stop/break on the Account controller's "public Task OnRemoteFailure(RemoteFailureContext context)" method. The debugger message gave me the full context of the error, an http 404 error and it gave the file name it was trying to find. Blob storage is case sensitive. The setup configuration used to configure B2C has camelCase names. The group who created the actual UI customization uses all lower case names. It took someone with access to all the assets to find the simple case name issue. Errors in distributed systems can be difficult.
I am working on my first WCF service and i am not sure why there are no results inspite of doing every correct.
Created a WCF service.Added a .svc page as well and now i can publish and browse to my service as well when it is hosted on IIS. Now i add service reference into a simple console application and create client object, provided values mandated by the data contract and then i do client.Operationname().
What is supposed to happen is that my service is supposed to send an email out to the email address i provided during my testing with a confirmation message.But that does not happen.
I enabled logging using SvcConfigEditor on the published config file, but there is no log entry.
I checked the logs of smtp and nothing is there as well.
I am running out of ideas as what else can i do to make sure that i am able to send out the confirmation email to the customer using my service. Also my service does work when i have it published on local machine.
Try to use WcfTestClient.exe from Visual Studio.Net Command-line to help simulate the client. then, You can debug the server side code.