I'm building a custom slack app with botkit framework and I'm trying to add a interaction button in my Bot/App.
I don't really catch one thing, as the botkit framework provides a way to have a webhook entry and setuped server to receive oauth requests and slack's requests for interactive buttons callbacks, does having a secured server with Https, certificate and all that stuff is mandatory for slack's API to perform POST requests on my server after hitting a interactive button?
Yes, a valid and non-self-signed SSL certificate is required to receive inbound requests on your server when message buttons are clicked by users. The certificate is also required for a few other outbound operations performed by Slack, like slash command executions and the Events API.
While in development, many developers use a tool like ngrok to proxy their requests, though it's not really appropriate for production use.
Related
I have a redirect widget that calls the AWS Lambda using AWS API Gateway. it returns a twiml-gather then will call an external API base on the output I receive on the twiml-gather
for security reasons, I would like to make my AWS API Gateway have an OAuth or API key
right now, I'm not sure how can i achieve this given that using the redirect widget doesnt have an option to input a http-headers (can't use the Twilio function because of 10 seconds time limit)
You can make use of the X-Twilio-Signature here.
You also find some Twilio blog posts on this topic.
Validating Requests are coming from Twilio
https://www.twilio.com/docs/usage/security
If your application exposes sensitive data, or is possibly mutative to your data, then you may want to be sure that the HTTP requests to your web application are indeed coming from Twilio, and not a malicious third party. To allow you this level of security, Twilio cryptographically signs its requests.
I want to create a Slack bot which will monitor incoming messages of channel, and respond to those messages based on the content using Events and Web API.
In Events API, the verification URL which I am currently using requires Shibboleth login i.e I need to put in username and password if I want to access that URL through browser.
How do I have Slack send its request to that URL? Currently Slack gets HTTP 500 error from the server, and also my server doesn't get any hit.
After talking to Slack help chat, I was told that Slack can't do auth. I was suggested to use proxy of some kind, but I ended up removing the Shibboleth from my server. Slack does sign every request it sends, so to have server respond to attackers, verify each request is from Slack before responding.
I have a mobile and web application to stream music. Here is my actual architecture:
RESTful service (Spring Boot)
Spring Security
OAuth2
HTTPS with domain certificated by CA
The questions is:
How can I make a communication exclusively between my mobile clients and back-end? (same thing between web client and back-end)
My suggestion is to split the problem in two parts - create two web services:
One back-end for mobile apps (without CRSF protection) with user certificate.
One back-end for web player (with CRSF protection) accepting requests only from web player's domain.
For mobile problem,
I'm able to intercept my mobile requests via proxy using Fiddler, decrypting HTTPS and getting important information like URL, headers, tokens.
But I know that there is an approach to avoid it making requests rejected when intercepted by another CA, like a exclusively trusted communication between back-end and mobile apps. How can I do that for mobile solution?
For web player problem,
he problem is bigger because browser will show headers, urls and tokens to anyone.
As I can't hide these information like mobile app do, I could make my back-end accept requests only from web player's domain. What is the best solution for this case?
UPDATED
Decompile mobile client is simpler than I imagined. As I can't protect/ofuscate keys, tokens and urls, my suggestion is to limit requests per user's token on back-end. But how can I do that on web player? I have the same token for anyone (no user's authentication).
I found this documment about decompile mobile clients.
http://pt.slideshare.net/denimgroup/developing-secure-mobile-applications-17732256
I would suggest you to use asymmetric cryptography. You request a public key from a server, and encrypt all following communication with it. And only your back-end will understand what you are sending to it, because only it has a private key to decrypt a message.
Note that your users still will be able to extract unencrypted data
directly from client memory. And you have no real way to disallow this!
I would like to make application for mobile/iPhone/iPad.
In app I would like to make an HTTP request to a web service.
How can I ensure that this request comes from my app or desktop browser or mobile browser.
The user can change the "user agent" string in the HTTP request header.
So please any one tell me how can we do that?
You can't be 100% certain, you can just take certain steps to be almost certain.
Start by using SSL between the app and the server, that way no one can intercept traffic.
Then create an API token that is hardcoded in the app itself, and is supplied to the API with every request. The API then rejects any request with an invalid API token.
Using a custom user-agent can help, again rejecting any request that doesn't match the user agent.
There are countless things you can do to make it HARDER for people to make API requests, but it's almost impossible to guarantee the request is from the app itself. Just make sure that all API endpoints are properly secured with some kind of 'user' authentication and you should be alright.
I'd definitely recommend using SSL whatever you do though, as if you use things like API keys without SSL, then someone could intercept the request and obtain the API key rendering it useless.
I am desiging a RESTful Web Service (JBoss + RESTeasy). The UI programmer is writing an Ajax web app that will use it. The web app will be one HTML page with everything done in JavaScript. For security, all traffic goes through SSL.
Currently I'm using Basic authentication. The UI programmer can show a dialog to get a username and password and put "Authorization: Basic xxxxx" in the header. Unfortunately if the password is wrong, the ugly browser login dialog box comes up. Also there is no way for the user to log off. This is unacceptable.
There appears to be no way to intercept a 401 response to an XMLHttpRequest in any of the browsers we will use.
Form-based authentication won't work for us. We need an automatic logoff after some period of inactivity (the equivalent of a session timeout). We can't have the server suddenly return a login page when the client expects a JSON object.
JBoss offers four authentication strategies: BASIC, FORM, CLIENT-CERT and DIGEST. I think DIGEST has the same problem as BASIC. None of the four is what we want.
This web application will be the only client (for now) so there is no requirement to use BASIC. Is there any other authentication strategy I can install? For instance is there an implementation of WSSE UsernameToken I can use? (As described in Chapter 8 of the O'Reilly RESTful Web Services book.) The server would send "WSSE" instead of "Basic" in the WWW-Authenticate header and presumably the browser would ignore it and pass it right through.
I want to configure security where it belongs -- in the JBoss configuration files, not in my RESTful Web Service -- so I'm looking for an implementation I can just plug into JBoss.
The browser won't present the password dialog if it doesn't recognize the authentication scheme in the WWW-Authenticate header. Your best bet may be to continue using basic auth on the server while setting the header manually to something like "Basic/MyApp" for 401 responses.