In our application, during the security testing, they were able to get the request and response details from the memory dump.
Please find the following details they were able to get from the dump, is there any option or process we can implement to remove this from happening:
CordovaHttpPlugin
post https:/XXXXXXXXXX/XXXXXXXXXX/login
username: XXXXXXXX
password XXXXXXX
json
Authorization
Bearer
null
Content-Type
application/json
Accept
text
ionic
Security team is using tool "fridump" for getting the memory data.
Is there any possible methods in ionic or tools that we can add to avoid this type of memory dump.
We were not able to resolve the issue. The security team advised us to prevent the application from installing in a rooted device for now, and also have all the data saved in the mobile side encrypted.
Related
I'm new to JMeter and trying to create test case.The application is using OAuth 2.0 azure active directory authentication,I followed one the post https://blog.pnop.co.jp/jmeter-webapps-azuread-auth_en/ and was able to do http request to app but in return I'm getting below error:
We can't sign you in
Your browser is currently set to block cookies. You need to allow cookies to use this service.
Cookies are small text files stored on your computer that tell us when you're signed in. To learn how to allow cookies, check the online help in your web browser.
I took care of CookieManager.save.cookies=true in user.properties but still cookies are giving me hard-time though I could see cookies populating in request header being sent
If someone have a crack of similar scenario then that would be great help
Thanks
Have you added HTTP Cookie Manager to your test plan?
If yes and you're still experiencing problems try:
Checking jmeter.log file for any suspicious entries
Choose a more "relaxed" implementation for the cookie manager, i.e. netscape
Add the next line to user.properties file:
CookieManager.check.cookies=false
JMeter restart will be required to pick up the change
More information: HTTP Cookie Manager Advanced Usage - A Guide
I am trying to fix the issues in IBM AppScan results and I\m getting the flag:
AppScan identified a password parameter that was received in the query string
with this command showing in the screen
GET /myapp.com/?username=user&password=**CONFIDENTIAL 1** HTTP/1.1
and I’m 100% sure that I'm not sending critical information in query params or even get requests I was thinking the about that the app is sending the request it self and want's me to block it.
Am I right or I'm missing something here?
It's quite common for application vulnerability scanners to misinterpret login forms that use JavaScript to make login requests. I am guessing the HTML form does not explicitly declare the request method as POST. Assuming when a user actually makes a request with a browser, a POST request is made, it's safe to assume that AppScan is generating this request itself.
One more issue to consider, if you make the request to https://myapp.com/?username=user&password=password#123, does that return a session token? This is often considered a vulnerability as well if the server does not reject all GET requests even if a user crafts it manually.
I'm developing both server and client side of a web application and it is almost finish. Now, it is time to secure it.
I read lots of articles and Q-A sites to understand the principles of the concept. But there are still question marks on my mind.
There is a similar question here:
How do I secure REST API calls?
They suggested to use token-based security system, which is very common and practical way. Also services like Firebase, Auth0 are providing this security system.
And this is about "how and where to store token": https://auth0.com/docs/security/store-tokens
If so, how can token protect server from fake-calls while we are storing it in the browsers local storage?
Explaining it with an example in order to be clear:
My client-side code has a form with options. One of the option can be selected via drop down option and there are only "1,2,3,4" in those options. So that, client can never send a form with "5" value to the server. But what if someone use a API tool (for example postman) to send a form with a value of 5? Attacker still can add a token to that request. First login to system as normal user. Than open the developer console of the browser, copy your token and paste to the header of your fake-request.
Not allowing the cross origin calls may solve the problem. But I am not sure if this means server and client should run on the same domain (or host)?
Bonus from stackoverflow: Stackoverflow's use of localstorage for Authorization seems unsafe. Is this correct else how do we strengthen it?
They are also discussing the similar question from another aspect. (Not for the server security but for the user's security.)
Not related but in case of need: front-end is developed with Angular 5, server is developed with Java and Spring Framework.
I'm developing an application using Chrome Native Messaging that starts through a Chrome Extension.
My question is: How can I ensure that host application is really the same supplied by me?
I need to ensure the authenticity the application called by extension. How do I get it if I don´t have permission to read registry or check if something was changed?
That is an excellent question, and my guess is the answer is "unfortunately, you can't".
It would be interesting to implement some sort of cryptographic hash like the ones Chrome uses to verify extension files, but that's not a very strong guarantee.
Consider (all of this hypothetical):
You can secure the registry entry / manifest pretty easily this way, but what about the file itself?
Suppose you pin a hash of the executable, then it becomes painful to update it (you'll have to update the extension too in sync). Can be resolved with some kind of public key signature though instead of a hash.
Suppose you pin the executable in the manifest. What about its data files? More importantly, what about the libraries a native app uses?
Securing a Chrome extension/app is easy, since the only "library"/runtime you rely on is Chrome itself (and you put trust into that). A native app can depend on many, many things on the system (like the already mentioned libraries), how do you keep track?
Anyway, this seems like an interesting thing to brainstorm. Take a look the Chrome bug tracker if there is already anything similar, if not - try to raise a feature request. Maybe try some Chromium-related mailing list to ask the devs.
I realize this is an older post, but I thought it would be worth sharing the Chromium team's official response from the bug I filed: https://bugs.chromium.org/p/chromium/issues/detail?id=514936
An attacker who can modify registry or the FS on the user's machine can also modify the chrome binary, and so any type of validation implemented in chrome can be disabled by such attacker by mangling with the chrome's code. For that reason chrome has to trust FS (and anything that comes from local machine).
If i understood the question correctly,The solution could be
Register your executable with your server while installing along with signing the executable and store your register number inside the executable and server
In Each Request (postMessage) from extension ,send a token in addition which was given by your server
Ask the server for the Next token to send response to the extension by passing the token from extension along with you registry number
Server will respond with the token if you are a registered user
Encrypt it with your registry number and send it to extension along with the token from extension
extension holder browser will ask the server its a good response
With the help of extension token the server will identify the executable registry number and decrypt the executable token and verify which was generated by us(server) for the extension token
Once server confirmed ,Browser will consider it as a response
To be important your registry number should be secure and the client machine cannot able to get it out from the executable(Using proper signing it can be achievable)
As chrome stopped support for Applet ,I implemented the same for smart card reader in chrome
The only loop hole is,The client machine can able to trace each and every request its sending with the help of some tools
If you are able to make your executable communication with your server be secure using some httpOnly Cookie(Client machine cannot able to read) or else the password mechanism ,Most probably a secure solution you can achieve
I've just compiled QTweetLib on my linux host. I've compiled and run pinauthstatusupdate example without any changes. But when I try to get request_token I've get:
Failed to validate oauth signature and token
I synced time on my host:
using sudo ntpdate pool.ntp.org
But no changes...
The I changed consumer keys with keys which Twitter creates for my application. But I got same problem.
I checked the base string using http://quonos.nl/oauthTester/ and it says my base string is OK.
Here is raw header which QTweetLib creates:
OAuth
oauth_consumer_key="YImPrR11sLxv0ZjjKAskA",oauth_signature_method="HMAC-SHA1",oauth_signature="WQnBaTgyuU6HkPT7DqTkNK1MT5c%3D",oauth_timestamp="1325542113",oauth_nonce="J5oUsjoOE34e1iTE",oauth_version="1.0"
So what's the problem?
According to QTweetLib's readme it supports only xAuth. Is your Twitter application xAuth enabled? If not you need to request it to be enabled for your application by sending email to api#twitter.com and stating some valid reasons why you can't just use OAuth.
Have you looked at KQOAuth (http://www.d-pointer.com/solutions/kqoauth/)? It supports 'normal' OAuth by utilizing the web browser of the environment and a temporary local web server. I think I read somewhere that it might get integrated to Qt5 in some form and thus it would probably be a safer bet than QTweetLib.