I am running a python based server inside a container. I can access it inside my host machine
curl --header "Content-Type: application/json" --request POST --data '{"uid":"admin","password":"admin"}' http://localhost:9000/auth
Result:
{"access_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJleHAiOjE1OTA4Mjk1NDAsImlhdCI6MTU5MDgyNTk0MCwibmJmIjoxNTkwODI1OTQwLCJzdWIiOiJhZG1pbiJ9.iTexlDupUMYYrodw44GI9ZnsTXnl5MurAXq6JCfqM0A"}
But now i am trying to do same curl inside another container, But It gives me access denied error.
Note: Unnecessary use of -X or --request, POST is already inferred.
* Expire in 0 ms for 6 (transfer 0x564809d7ff50)
* Uses proxy env variable http_proxy == 'http://10.223.4.20:911'
* Trying 10.223.4.20...
* TCP_NODELAY set
* Expire in 200 ms for 4 (transfer 0x564809d7ff50)
* Connected to 10.223.4.20 (10.223.4.20) port 911 (#0)
> POST http://localhost:9000/auth HTTP/1.1
> Host: localhost:9000
> User-Agent: curl/7.64.0
> Accept: */*
> Proxy-Connection: Keep-Alive
> Content-Type: application/json
> Content-Length: 34
>
* upload completely sent off: 34 out of 34 bytes
< HTTP/1.1 403 Forbidden
< Cache-Control: no-cache
< Pragma: no-cache
< Content-Type: text/html; charset=utf-8
< Proxy-Connection: Keep-Alive
< Connection: Keep-Alive
< Content-Length: 642
<
<HTML><HEAD>
<TITLE>Access Denied</TITLE>
</HEAD>
<BODY>
<FONT face="Helvetica">
<big><strong></strong></big><BR>
</FONT>
<blockquote>
<TABLE border=0 cellPadding=1 width="80%">
<TR><TD>
<FONT face="Helvetica">
<big>Access Denied (policy_denied)</big>
<BR>
<BR>
</FONT>
</TD></TR>
<TR><TD>
<FONT face="Helvetica">
Your system policy has denied access to the requested URL.
</FONT>
</TD></TR>
<TR><TD>
<FONT face="Helvetica">
</FONT>
</TD></TR>
<TR><TD>
<FONT face="Helvetica" SIZE=2>
<BR>
For assistance, contact your network support team.
</FONT>
</TD></TR>
</TABLE>
</blockquote>
</FONT>
</BODY></HTML>
* Connection #0 to host 10.223.4.20 left intact
All the containers are mapped as network_mode: host.
Here is my Docker-compose.yml
version: '2'
services:
tacotron:
image: tacotron-image
network_mode: host
command: python3 runserver.py
tts_driver:
image: tts_driver
privileged: true
network_mode: host
environment:
- ASR_PUB_PORT=5555
- ASR_PUB_TOPIC=subnlptopic
- TTS_DRIVER_PUB_PORT=5556
- TTS_DRIVER_PUB_TOPIC=pubttstopic
command: python3 /app/TTSDriver.py
What i am doing wrong here?
Thanks
Akshay
Related
Our React Development build runs flawless with Express Gateway setup on localhost. After build React for production and when we run serve -s build login page comes as it is the entry point of the app. It gets 200 ok response when we put sign-in credential. But when we looked into it we can see the request to server was not successful cause token it saves to browser application is undefined and we checked the response, It is "You need to enable javascript...". JS is enabled no doubt. I have checked By using
axios.post('http://localhost:8080/api/v1/auth/sign-in', userData)
It works fine but when setup proxy:
axios.post('/auth/sign-in', userData)
react doesn’t run
Here is the part of yml for express gateway setup:
http:
port: 8080
apiEndpoints:
auth-service:
host: "*"
paths: ["/api/v1/auth/*", "/api/v1/auth"]
mail-service:
host: "*"
paths: ["/api/v1/mail/*", "/api/v1/mail"]
serviceEndpoints:
auth-service-endpoint:
url: http://localhost:3003/
mail-service-endpoint:
url: http://localhost:3005/
policies:
- proxy
pipelines:
auth-service-pipeline:
apiEndpoints:
- auth-service
policies:
- proxy:
action:
serviceEndpoint: auth-service-endpoint
changeOrigin: true
stripPath: true
mail-service-pipeline:
apiEndpoints:
- mail-service
policies:
- proxy:
action:
serviceEndpoint: mail-service-endpoint
changeOrigin: true
stripPath: true
I put the setupProxy.js on src directory of React:
const { createProxyMiddleware } = require('http-proxy-middleware');
module.exports = function(app) {
app.use(createProxyMiddleware('/api/v1',
{ target: 'http://localhost:8080',
secure: false,
changeOrigin: true,
// pathRewrite: {
// "^/api": "/api/v1",
// }
}
));
}
Currently everything is on same machine. We are not using docker.
The application runs on Dev environment but shows 200 ok response in production build
Any help will be appreciated.
[Edit]
krypton:admin-dashboard-server hasan$ curl -v http://localhost:3001/find_all_services/1/10
* Trying ::1...
* TCP_NODELAY set
* Connected to localhost (::1) port 3001 (#0)
> GET /find_all_services/1/10 HTTP/1.1
> Host: localhost:3001
> User-Agent: curl/7.54.0
> Accept: */*
>
< HTTP/1.1 200 OK
< Access-Control-Allow-Origin: *
< X-DNS-Prefetch-Control: off
< X-Frame-Options: SAMEORIGIN
< Strict-Transport-Security: max-age=15552000; includeSubDomains
< X-Download-Options: noopen
< X-Content-Type-Options: nosniff
< X-XSS-Protection: 1; mode=block
< Content-Type: application/json; charset=utf-8
< Content-Length: 1833
< ETag: W/"729-LM91B3vCUrbvesBrp32ykiXXkQo"
< Date: Tue, 12 Jan 2021 14:57:24 GMT
< Connection: keep-alive
<
* Connection #0 to host localhost left intact
[{"id":1,"name":"Laser Hair Remove"},
{"id":2,"name":"Facial Treatments"}
]
krypton:admin-dashboard-server hasan$ curl -v
http://localhost:8080/api/v1/services/find_all_services/1/10
* Trying ::1...
* TCP_NODELAY set
* Connected to localhost (::1) port 8080 (#0)
> GET /api/v1/services/find_all_services/1/10 HTTP/1.1
> Host: localhost:8080
> User-Agent: curl/7.54.0
> Accept: */*
>
< HTTP/1.1 200 OK
< access-control-allow-origin: *
< x-dns-prefetch-control: off
< x-frame-options: SAMEORIGIN
< strict-transport-security: max-age=15552000; includeSubDomains
< x-download-options: noopen
< x-content-type-options: nosniff
< x-xss-protection: 1; mode=block
< content-type: application/json; charset=utf-8
< content-length: 1833
< etag: W/"729-LM91B3vCUrbvesBrp32ykiXXkQo"
< date: Tue, 12 Jan 2021 15:03:45 GMT
< connection: keep-alive
<
* Connection #0 to host localhost left intact
[{"id":1,"name":"Laser Hair Remove"},
{"id":2,"name":"Facial Treatments"}
]
krypton:admin-dashboard-server hasan$ curl -v -H "Content-Type: application/json" -X POST -d
'{"email":"mh.mithun#gmail.com","password":"safe123"}'
http://localhost:8080/api/v1/auth/sign-in
Note: Unnecessary use of -X or --request, POST is already inferred.
* Trying ::1...
* TCP_NODELAY set
* Connected to localhost (::1) port 8080 (#0)
> POST /api/v1/auth/sign-in HTTP/1.1
> Host: localhost:8080
> User-Agent: curl/7.54.0
> Accept: */*
> Content-Type: application/json
> Content-Length: 52
>
* upload completely sent off: 52 out of 52 bytes
< HTTP/1.1 200 OK
< access-control-allow-origin: *
< x-dns-prefetch-control: off
< x-frame-options: SAMEORIGIN
< strict-transport-security: max-age=15552000; includeSubDomains
< x-download-options: noopen
< x-content-type-options: nosniff
< x-xss-protection: 1; mode=block
< content-type: application/json; charset=utf-8
< content-length: 270
< etag: W/"10e-S+kd8b4Yfl7un04FVGe3MFLFEaY"
< date: Tue, 12 Jan 2021 15:40:12 GMT
< connection: keep-alive
<
* Connection #0 to host localhost left intact
"eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJhbGdvcml0aG0iOiJIUzI1N"
krypton:admin-dashboard-server hasan$ curl -v -H "Content-Type: application/json" -X POST -d '{"email":"mh.mithun#gmail.com","password":"safe123"}' http://localhost:3003/sign-in
Note: Unnecessary use of -X or --request, POST is already inferred.
* Trying ::1...
* TCP_NODELAY set
* Connected to localhost (::1) port 3003 (#0)
> POST /sign-in HTTP/1.1
> Host: localhost:3003
> User-Agent: curl/7.54.0
> Accept: */*
> Content-Type: application/json
> Content-Length: 52
>
* upload completely sent off: 52 out of 52 bytes
< HTTP/1.1 200 OK
< Access-Control-Allow-Origin: *
< X-DNS-Prefetch-Control: off
< X-Frame-Options: SAMEORIGIN
< Strict-Transport-Security: max-age=15552000; includeSubDomains
< X-Download-Options: noopen
< X-Content-Type-Options: nosniff
< X-XSS-Protection: 1; mode=block
< Content-Type: application/json; charset=utf-8
< Content-Length: 270
< ETag: W/"10e-LW/1l5fXf5BaiF3KJMvG60xRthE"
< Date: Tue, 12 Jan 2021 15:45:33 GMT
< Connection: keep-alive
<
* Connection #0 to host localhost left intact
"eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJhbGdvcml0aG0i"
I have an API server running at localhost:3000 and I am trying to query it using these two expressions:
[wani#lenovo ilparser-docker]$ time (curl "localhost:3000/parse?lang=hin&data=देश" )
{"tokenizer":"<Sentence id=\"1\">\n1\tदेश\tunk\n<\/Sentence>\n"}
real 0m0.023s
user 0m0.009s
sys 0m0.004s
[wani#lenovo ilparser-docker]$ time (curl -XGET localhost:3000/parse -F lang=hin -F data="देश" )
{"tokenizer":"<Sentence id=\"1\">\n1\tदेश\tunk\n<\/Sentence>\n"}
real 0m1.101s
user 0m0.020s
sys 0m0.070s
Why does the second expression take so much more time?
With more verbosity:
[wani#lenovo ilparser-docker]$ time curl -v localhost:3000/parse -F lang=hin -F data="देश"
* Trying 127.0.0.1...
* Connected to localhost (127.0.0.1) port 3000 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
> POST /parse HTTP/1.1
> Host: localhost:3000
> User-Agent: curl/7.43.0
> Accept: */*
> Content-Length: 244
> Expect: 100-continue
> Content-Type: multipart/form-data; boundary=------------------------1eb5e5991b976cb1
>
* Done waiting for 100-continue
< HTTP/1.1 200 OK
< Content-Length: 70
< Server: Mojolicious (Perl)
< Content-Type: application/json;charset=UTF-8
< Date: Mon, 21 Mar 2016 11:06:09 GMT
< Connection: keep-alive
<
* Connection #0 to host localhost left intact
{"tokenizer":"<Sentence id=\"1\">\n1\tदेश\tunk\n<\/Sentence>\n"}
real 0m1.106s
user 0m0.027s
sys 0m0.068s
[wani#lenovo ilparser-docker]$ time curl -v localhost:3000/parse --data lang=hin --data data="देश"
* Trying 127.0.0.1...
* Connected to localhost (127.0.0.1) port 3000 (#0)
> POST /parse HTTP/1.1
> Host: localhost:3000
> User-Agent: curl/7.43.0
> Accept: */*
> Content-Length: 23
> Content-Type: application/x-www-form-urlencoded
>
* upload completely sent off: 23 out of 23 bytes
< HTTP/1.1 200 OK
< Server: Mojolicious (Perl)
< Content-Length: 70
< Connection: keep-alive
< Date: Mon, 21 Mar 2016 11:06:24 GMT
< Content-Type: application/json;charset=UTF-8
<
* Connection #0 to host localhost left intact
{"tokenizer":"<Sentence id=\"1\">\n1\tदेश\tunk\n<\/Sentence>\n"}
real 0m0.031s
user 0m0.011s
sys 0m0.003s
Expect: 100-continue sounded fishy, so I cleared that header:
[wani#lenovo ilparser-docker]$ time curl -v -F lang=hin -F data="देश" "localhost:3000/parse" -H Expect: --trace-time
16:48:04.513691 * Trying 127.0.0.1...
16:48:04.513933 * Connected to localhost (127.0.0.1) port 3000 (#0)
16:48:04.514083 * Initializing NSS with certpath: sql:/etc/pki/nssdb
16:48:04.610095 > POST /parse HTTP/1.1
16:48:04.610095 > Host: localhost:3000
16:48:04.610095 > User-Agent: curl/7.43.0
16:48:04.610095 > Accept: */*
16:48:04.610095 > Content-Length: 244
16:48:04.610095 > Content-Type: multipart/form-data; boundary=------------------------24f30647b16ba82d
16:48:04.610095 >
16:48:04.618107 < HTTP/1.1 200 OK
16:48:04.618194 < Content-Length: 70
16:48:04.618249 < Server: Mojolicious (Perl)
16:48:04.618306 < Content-Type: application/json;charset=UTF-8
16:48:04.618370 < Date: Mon, 21 Mar 2016 11:18:04 GMT
16:48:04.618430 < Connection: keep-alive
16:48:04.618492 <
16:48:04.618590 * Connection #0 to host localhost left intact
{"tokenizer":"<Sentence id=\"1\">\n1\tदेश\tunk\n<\/Sentence>\n"}
real 0m0.117s
user 0m0.023s
sys 0m0.082s
Now the only time taking thing left is: Initializing NSS with certpath: sql:/etc/pki/nssdb. Why does curl do that in this context?
After a little help on IRC from #DanielStenberg, I came to know that the db load is present because curl inits nss in that case since curl needs a good random source for the boundary separator used for -F . Curl could have used getrandom() syscall or read bits out of /dev/urandom since boundary separators don't need to be cryptographically secure in any way, but curl just wants secure random in some other places so curl reuses the random function that it already has.
I've installed a Geotrust certificate for my site, which run over IIS7. The certificate is correctly installed, but I am getting an unexpected result. When I make a request to a http://example.com, it Works well on every browser/device, but when I make a request to https://example.com, it only responds in some browsers/devices, examples:
- On the same PC respond well only in Firefox, but not in IE or Chrome.
- On others PCs not respond to any browsers.
- The strangest, in my Smartphone, not respond through wifi, but when I am connected over 3G the site respond properly to https.
- I also test in a labtop, via wifi the site dont respond, but if I share the 3g connection from the Smartphone to the labtop, the web Works properly.
EDIT: the result of the openssl command:
Loading 'screen' into random state - done
CONNECTED(000001C4)
depth=2 C = US, O = GeoTrust Inc., CN = GeoTrust Global CA
verify error:num=20:unable to get local issuer certificate
verify return:0
---
Certificate chain
0 s:/C=ES/ST=Malaga/L=Malaga/O=domain/CN=www.domain.net/OU=domain
i:/C=US/O=GeoTrust Inc./CN=GeoTrust SSL CA - G2
1 s:/C=US/O=GeoTrust Inc./CN=GeoTrust SSL CA - G2
i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
2 s:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIExjCCA66gAwIBAgIQeee0uwSySeNXOkI+BUoMMzANBgkqhkiG9w0BAQUFADBE
MQswCQYDVQQGEwJVUzEWMBQGA1UEChMNR2VvVHJ1c3QgSW5jLjEdMBsGA1UEAxMU
...
doLsKI2R6RQA/7IcuTpKkvLF5wYKvmocPxYVg9FOoFvKV0wjWo6qlwsANPAVov+7
zFzZreROa7lBj8UH0IyYjLmBrbe1yMr/Cmg=
-----END CERTIFICATE-----
subject=/C=ES/ST=Malaga/L=Malaga/O=domain/CN=www.domain.net/OU=domain
issuer=/C=US/O=GeoTrust Inc./CN=GeoTrust SSL CA - G2
---
No client certificate CA names sent
---
SSL handshake has read 3405 bytes and written 645 bytes
---
New, TLSv1/SSLv3, Cipher is AES128-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1
Cipher : AES128-SHA
Session-ID: D80B0000C341A313FBA6527E6576D1D71ACA71E680528EE880649C8166AA7C1B
Session-ID-ctx:
Master-Key: F1D5AB2E543959B3D100CC16365884DEFF06E56E3C57839A64088744FFCAEDCE
24B744836326E46828537C64884081B0
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1407168950
Timeout : 300 (sec)
Verify return code: 20 (unable to get local issuer certificate)
---
After some searching and testing some ideas I have not done anything and I'm going crazy. Any idea?
... but when I make a request to https://example.com, it only responds in some browsers/devices...
OK, the certificate chain looks OK. I grabbed your server's name out of the cert you posted for the tests below. You can run your certificate through openssl x509 and see the CN and SAN:
$ openssl x509 -in server-cert.pem -inform PEM -text -noout
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
79:e7:b4:bb:04:b2:49:e3:57:3a:42:3e:05:4a:0c:33
Signature Algorithm: sha1WithRSAEncryption
Issuer: C=US, O=GeoTrust Inc., CN=GeoTrust SSL CA - G2
Validity
Not Before: Jun 11 00:00:00 2014 GMT
Not After : Jun 11 23:59:59 2015 GMT
Subject: C=ES, ST=Malaga, L=Malaga, O=Example, CN=www.example.com, OU=Example, LLC
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:a2:f6:fd:b0:30:10:91:55:3f:ec:ce:fa:d8:9e:
84:cd:60:c4:dd:a8:f0:42:37:66:a9:98:80:35:d8:
...
13:db:e9:98:c5:1a:ac:31:50:70:e1:6e:8d:1f:2a:
7d:b5
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Subject Alternative Name:
DNS:www.example.com, DNS:example.com
X509v3 Basic Constraints:
CA:FALSE
X509v3 Key Usage: critical
Digital Signature, Key Encipherment
X509v3 CRL Distribution Points:
Full Name:
URI:http://gb.symcb.com/gb.crl
X509v3 Certificate Policies:
Policy: 2.16.840.1.113733.1.7.54
CPS: https://d.symcb.com/cps
User Notice:
Explicit Text: https://d.symcb.com/rpa
X509v3 Extended Key Usage:
TLS Web Server Authentication, TLS Web Client Authentication
X509v3 Authority Key Identifier:
keyid:11:4A:D0:73:39:D5:5B:69:08:5C:BA:3D:BF:64:9A:A8:8B:1C:55:BC
Authority Information Access:
OCSP - URI:http://gb.symcd.com
CA Issuers - URI:http://gb.symcb.com/gb.crt
Signature Algorithm: sha1WithRSAEncryption
52:60:0e:f3:c7:fb:16:49:cf:4f:7c:91:d9:c9:b9:d5:92:62:
75:c9:05:f1:b7:cf:ea:30:53:44:5d:a7:1e:c7:eb:fd:a9:ab:
...
e4:4e:6b:b9:41:8f:c5:07:d0:8c:98:8c:b9:81:ad:b7:b5:c8:
ca:ff:0a:68
You have both example.com and www.example.com. That is OK.
One small nitpick. Placing a DNS name in the Common Name (CN) is deprecated by both the IETF and CA/Browser forums. DNS names should be placed in the Subject Alternate Name (SAN). Put a friendly name in the CN because its usually displayed to the user.
The issue should not produce the problem you are experiencing. In fact, I use Startcom certificates for my web and mail server and have never had an issue.
Next, OpenSSL's "Verify return code: 20 (unable to get local issuer certificate)" complaint is because you are not using CAfile option with <Equifax Secure Certificate Authority>.pem. If interested, you can download it from GeoTrust Root Certificates. I'll use it below to ensure a "Verify return code: 0 (ok)".
Now, check this out (SSLv3):
$ echo -e "GET / HTTP/1.1\n" | openssl s_client -connect example.com:443 \
-ssl3 -ign_eof -CAfile Equifax_Secure_Certificate_Authority.pem
CONNECTED(00000003)
depth=3 C = US, O = Equifax, OU = Equifax Secure Certificate Authority
verify return:1
depth=2 C = US, O = GeoTrust Inc., CN = GeoTrust Global CA
verify return:1
depth=1 C = US, O = GeoTrust Inc., CN = GeoTrust SSL CA - G2
verify return:1
depth=0 C = ES, ST = Malaga, L = Malaga, O = Example, LLC, CN = www.example.com, OU = Example, LLC
verify return:1
---
Certificate chain
0 s:/C=ES/ST=Malaga/L=Malaga/O=Example, LLC/CN=www.example.com/OU=Example, LLC
i:/C=US/O=GeoTrust Inc./CN=GeoTrust SSL CA - G2
1 s:/C=US/O=GeoTrust Inc./CN=GeoTrust SSL CA - G2
i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
2 s:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority
---
...
Start Time: 1407401571
Timeout : 7200 (sec)
Verify return code: 0 (ok)
---
HTTP/1.1 400 Bad Request
Content-Type: text/html; charset=us-ascii
Server: Microsoft-HTTPAPI/2.0
Date: Thu, 07 Aug 2014 08:52:28 GMT
Connection: close
Content-Length: 334
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN""http://www.w3.org/TR/html4/strict.dtd">
<HTML><HEAD><TITLE>Bad Request</TITLE>
<META HTTP-EQUIV="Content-Type" Content="text/html; charset=us-ascii"></HEAD>
<BODY><h2>Bad Request - Invalid Hostname</h2>
<hr><p>HTTP Error 400. The request hostname is invalid.</p>
</BODY></HTML>
read:errno=0
And (TLS 1.0 with SNI):
$ echo -e "GET / HTTP/1.1\n" | openssl s_client -connect example.com:443 \
-tls1 -servername example.com -ign_eof -CAfile Equifax_Secure_Certificate_Authority.pem
CONNECTED(00000003)
...
Start Time: 1407401898
Timeout : 7200 (sec)
Verify return code: 0 (ok)
---
HTTP/1.1 400 Bad Request
Content-Type: text/html; charset=us-ascii
Server: Microsoft-HTTPAPI/2.0
Date: Thu, 07 Aug 2014 08:57:55 GMT
Connection: close
Content-Length: 334
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN""http://www.w3.org/TR/html4/strict.dtd">
<HTML><HEAD><TITLE>Bad Request</TITLE>
<META HTTP-EQUIV="Content-Type" Content="text/html; charset=us-ascii"></HEAD>
<BODY><h2>Bad Request - Invalid Hostname</h2>
<hr><p>HTTP Error 400. The request hostname is invalid.</p>
</BODY></HTML>
read:errno=0
It does not appear to be Server Name Indication (SNI) related. I'm not sure SNI being honored at this point. Is this IIS 7.5 or below? IIS 8 provides SNI, and that might help the issue since the request will be routed immediately to the correct virtual domain in IIS.
Next, add a host header:
$ echo -e "GET / HTTP/1.1\nHost:example.com\n" | openssl s_client -connect example.com:443 \
-ssl3 -ign_eof -CAfile Equifax_Secure_Certificate_Authority.pem
CONNECTED(00000003)
...
Start Time: 1407402117
Timeout : 7200 (sec)
Verify return code: 0 (ok)
---
read R BLOCK
HTTP/1.1 302 Found
Cache-Control: private
Transfer-Encoding: chunked
Content-Type: text/html; charset=utf-8
Location: /Login/Login
Server: Microsoft-IIS/7.5
Set-Cookie: ASP.NET_SessionId=310xiuzver13lqoau0il0tsu; path=/; HttpOnly
X-AspNetMvc-Version: 3.0
X-AspNet-Version: 4.0.30319
X-Powered-By: ASP.NET
Date: Thu, 07 Aug 2014 09:01:34 GMT
The 302 redirect looks wrong. Shouldn't that be a 301? See HTTP redirect: 301 (permanent) vs. 302 (temporary). Also check out How can I make Chrome stop caching redirects? and the "won't fix" bug.
For completeness, here's the result following the redirect to /Login/Login:
$ echo -e "GET /Login/Login HTTP/1.1\nHost:example.com\n" | openssl s_client -connect example.com:443 \
-ssl3 -ign_eof -CAfile Equifax_Secure_Certificate_Authority.pem
CONNECTED(00000003)
...
Start Time: 1407403671
Timeout : 7200 (sec)
Verify return code: 0 (ok)
read R BLOCK
HTTP/1.1 200 OK
Cache-Control: private
Content-Type: text/html; charset=utf-8
Server: Microsoft-IIS/7.5
X-AspNetMvc-Version: 3.0
X-AspNet-Version: 4.0.30319
X-Powered-By: ASP.NET
Date: Thu, 07 Aug 2014 09:27:29 GMT
Content-Length: 1547
<html>
<body>
<form action="/Login/Login" method="post"> <div style="height: 140px">
</div>
<table style="width: 400px; border: 1px solid #058fbe;" cellpadding="5" align="center">
<tr>
<td colspan="2" align="center" style="background-color: #058fbe">
<span style="color: #FFF; font-family: Arial, Helvetica, sans-serif;
font-weight: bold; font-size: 14pt">TERRANET. ZONA ADMINISTRACIÓN</span>
</td>
</tr>
<tr>
<td width="150px">
<img src="/Content/img/login.png" width="150px" />
</td>
<td>
<span style="color: #058fbe; font-family: Arial, Helvetica, sans-serif;
font-weight: bold; font-size: 10pt">usuario</span><br />
<input type="text" style="border: 1px solid #058fbe; width: 190px" name="usuario" /><br />
<span style="color: #058fbe; font-family: Arial, Helvetica, sans-serif;
font-weight: bold; font-size: 10pt">contraseña</span><br />
<input type="password" style="border: 1px solid #058fbe; width: 190px" name="pass" /><br />
<br />
<input type="submit" value="entrar" style="background-color: #058fbe;
width: 80px; color: white; font-family: Arial, Helvetica, sans-serif;
font-weight: bold; font-size: 10pt; border: none" />
</td>
</tr>
</table>
</form>
</body>
</html>
EDIT (August 7, 2014): I see your changes of HTTP/1.1 301 Moved Permanently.
I performed some browsers tests today. I used:
Chrome (Mac Book)
Firefox (Mac Book)
Safari (Mac Book).
Mobile Browser (Android)
Mobile Chrome (iPhone)
Mobile Safari (iPhone)
Explorer (Surface Pro)
Most worked as expected.
Explorer on the Surface Pro tablet hung.
Android's browser (com.android.browser) prompted for a client cert (that's why I am being prompted to set a PIN):
Safari desktop prompted for a client cert:
Do you need client certificates? If so, that's probably the issue. Client side certificates are a mess in browsers.
If you don't need them, then disable them in IIS. See Specify Whether to Use Client Certificates (IIS 7).
This may be because of IP binding as to get it worked properly your HTTPS and HTTP both should bind to same IP address in IIS.
Have you tried restarting your IIS? it may resolve the issue.
I am trying to POST a JPEG image from a particular file directory to the server curl. This is what I typed:
curl -v -include --form filedata='/home/pi/Documents/2014-01-18-09:11:25.jpeg' http://hostdomain.me/file/upload
Upon executing this command, the following is returned from the Terminal:
* Couldn't find host rdnvpfwnwk.localtunnel.me in the .netrc file; using defaults
* About to connect() to rdnvpfwnwk.localtunnel.me port 80 (#0)
* Trying 192.34.58.73...
* connected
* Connected to rdnvpfwnwk.localtunnel.me (192.34.58.73) port 80 (#0)
> POST /file/upload HTTP/1.1
> User-Agent: curl/7.26.0
> Host: rdnvpfwnwk.localtunnel.me
> Accept: */*
> Content-Length: 186
> Expect: 100-continue
> Content-Type: multipart/form-data; boundary=----------------------------affc91df7bc3
>
* additional stuff not fine transfer.c:1037: 0 0
* HTTP 1.1 or later with persistent connection, pipelining supported
< HTTP/1.1 100 Continue
HTTP/1.1 100 Continue
* additional stuff not fine transfer.c:1037: 0 0
* additional stuff not fine transfer.c:1037: 0 0
* HTTP 1.1 or later with persistent connection, pipelining supported
< HTTP/1.1 500 Internal Server Error
HTTP/1.1 500 Internal Server Error
< Server: nginx
Server: nginx
< Date: Sat, 18 Jan 2014 11:44:39 GMT
Date: Sat, 18 Jan 2014 11:44:39 GMT
< Content-Type: text/plain
Content-Type: text/plain
< Content-Length: 9245
Content-Length: 9245
< Connection: keep-alive
Connection: keep-alive
< X-Powered-By: Sails <sailsjs.org>
X-Powered-By: Sails <sailsjs.org>
* Added cookie sails.sid="s%3AAucWnGhDSzZSGB_tBgSXJoU2.DMQ4FuVVRRGLFGheMgr4CvIFUICCiP9Gqd5GIjRevA8" for domain rdnvpfwnwk.localtunnel.me, path /, expire 0
< Set-Cookie: sails.sid=s%3AAucWnGhDSzZSGB_tBgSXJoU2.DMQ4FuVVRRGLFGheMgr4CvIFUICCiP9Gqd5GIjRevA8; Path=/; HttpOnly
Set-Cookie: sails.sid=s%3AAucWnGhDSzZSGB_tBgSXJoU2.DMQ4FuVVRRGLFGheMgr4CvIFUICCiP9Gqd5GIjRevA8; Path=/; HttpOnly
* HTTP error before end of send, stop sending
<
TypeError: Cannot read property 'name' of undefined
When using the form on the site it sends properly. Here is the form:
<form id="uploadForm"
enctype="multipart/form-data"
action="/file/upload"
method="post">
<input type="file" id="userPhotoInput" name="userPhoto" />
<input type="submit" value="Submit">
</form>
How can this be fixed?
use this :
curl -v -include --form "userPhoto=#/home/pi/Documents/2014-01-18-09:11:25.jpeg" http://hostdomain.me/file/upload
^^^^^^^^^ ^
We recently set up a website (http://www.doverjewelry.com/) with hikashop, the domain has godaddy website protection so it scans the website and warns against vulnerabilities. The scan is currently reporting the the website is vulnerable to cross-site scripting attacks. This the scan output:
Using the GET HTTP method, Site Scanner found that :
+ The following resources may be vulnerable to XSS (on parameters names) :
/bands-and-settings/category/371-all-ring-settings/limit_hikashop_catego
ry_information_module_223_371-0/limitstart_hikashop_category_information
_module_223_371-0/filter_order_hikashop_category_information_module_223_
371-a.ordering/filter_order_Dir_hikashop_category_information_module_223
_371-ASC/688ae9879a2df0fc5b840aeabd44a6ec-1/type-atom?<<<<<<<<<<foo"bar'
314>>>>>=1
-------- request --------
GET /bands-and-settings/category/371-all-ring-settings/limit_hikashop_category_information_module_223_371-0/limitstart_hikashop_category_information_module_223_371-0/filter_order_hikashop_category_information_module_223_371-a.ordering/filter_order_Dir_hikashop_category_information_module_223_371-ASC/688ae9879a2df0fc5b840aeabd44a6ec-1/type-atom?<<<<<<<<<<foo"bar'314>>>>>=1 HTTP/1.1\r
Host: www.doverjewelry.com\r
Accept-Charset: iso-8859-1,utf-8;q=0.9,*;q=0.1\r
Accept-Language: en\r
Connection: Close\r
Cookie: 7eedc822c6dd39ecf3c8ab00003d56f9=764a229107bda6b48c2863965f50ca03\r
User-Agent: Mozilla/5.0 (compatible; MSIE 7.0; MSIE 6.0; Site Scanner Bot; +http://www.websiteprotection.com) Firefox/2.0.0.3\r
Pragma: no-cache\r
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, image/png, */*
------------------------
-------- output --------
[...] bd44a6ec-1/type-atom?<<<<<<<<<<foo"bar'314>>>>>=1" method="post" name="ad [...]
<div class="hikashop_products_pagination hikashop_products_paginat [...]
------------------------
/engagement-rings/category/366-antique-engagement-rings/limit_hikashop_c
ategory_information_module_222_366-25/limitstart_hikashop_category_infor
mation_module_222_366-0/filter_order_hikashop_category_information_modul
e_222_366-a.ordering/filter_order_Dir_hikashop_category_information_modu
le_222_366-ASC/688ae9879a2df0fc5b840aeabd44a6ec-1/type-atom?<<<<<<<<<<fo
o"bar'314>>>>>=1
-------- request --------
GET /engagement-rings/category/366-antique-engagement-rings/limit_hikashop_category_information_module_222_366-25/limitstart_hikashop_category_information_module_222_366-0/filter_order_hikashop_category_information_module_222_366-a.ordering/filter_order_Dir_hikashop_category_information_module_222_366-ASC/688ae9879a2df0fc5b840aeabd44a6ec-1/type-atom?<<<<<<<<<<foo"bar'314>>>>>=1 HTTP/1.1\r
Host: www.doverjewelry.com\r
Accept-Charset: iso-8859-1,utf-8;q=0.9,*;q=0.1\r
Accept-Language: en\r
Connection: Close\r
Cookie: 7eedc822c6dd39ecf3c8ab00003d56f9=764a229107bda6b48c2863965f50ca03\r
User-Agent: Mozilla/5.0 (compatible; MSIE 7.0; MSIE 6.0; Site Scanner Bot; +http://www.websiteprotection.com) Firefox/2.0.0.3\r
Pragma: no-cache\r
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, image/png, */*
------------------------
-------- output --------
[...] bd44a6ec-1/type-atom?<<<<<<<<<<foo"bar'314>>>>>=1" method="post" name="ad [...]
<div class="hikashop_products_pagination hikashop_products_paginat [...]
------------------------
/engagement-rings/category/366-antique-engagement-rings/limit_hikashop_c
ategory_information_module_222_366-25/limitstart_hikashop_category_infor
mation_module_222_366-0/filter_order_hikashop_category_information_modul
e_222_366-a.ordering/filter_order_Dir_hikashop_category_information_modu
le_222_366-ASC/688ae9879a2df0fc5b840aeabd44a6ec-1/type-rss?<<<<<<<<<<foo
"bar'314>>>>>=1
-------- request --------
GET /engagement-rings/category/366-antique-engagement-rings/limit_hikashop_category_information_module_222_366-25/limitstart_hikashop_category_information_module_222_366-0/filter_order_hikashop_category_information_module_222_366-a.ordering/filter_order_Dir_hikashop_category_information_module_222_366-ASC/688ae9879a2df0fc5b840aeabd44a6ec-1/type-rss?<<<<<<<<<<foo"bar'314>>>>>=1 HTTP/1.1\r
Host: www.doverjewelry.com\r
Accept-Charset: iso-8859-1,utf-8;q=0.9,*;q=0.1\r
Accept-Language: en\r
Connection: Close\r
Cookie: 7eedc822c6dd39ecf3c8ab00003d56f9=764a229107bda6b48c2863965f50ca03\r
User-Agent: Mozilla/5.0 (compatible; MSIE 7.0; MSIE 6.0; Site Scanner Bot; +http://www.websiteprotection.com) Firefox/2.0.0.3\r
Pragma: no-cache\r
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, image/png, */*
------------------------
-------- output --------
[...] abd44a6ec-1/type-rss?<<<<<<<<<<foo"bar'314>>>>>=1" method="post" name="ad [...]
<div class="hikashop_products_pagination hikashop_products_paginat [...]
------------------------
/engagement-rings/category/50-estate-engagement-rings/limit_hikashop_cat
egory_information_module_222_50-0/limitstart_hikashop_category_informati
on_module_222_50-0/filter_order_hikashop_category_information_module_222
_50-a.ordering/filter_order_Dir_hikashop_category_information_module_222
_50-ASC/688ae9879a2df0fc5b840aeabd44a6ec-1/type-atom?<<<<<<<<<<foo"bar'3
14>>>>>=1
We think it is refering to the pagination form at the bottom of the product pages. Here is the form code for one of the product pages:
<form action="http://www.doverjewelry.com/engagement-rings/category/50-estate-engagement-rings?filter_order_hikashop_category_information_module_222_50=%3C%3C%3C%3C%3C%3C%3C%3C%3C%3Cfoo%22bar'204%3E%3E%3E%3E%3E" method="post" name="adminForm_hikashop_category_information_module_222_50_bottom">
<div class="hikashop_products_pagination hikashop_products_pagination_bottom">
<div class="list-footer">
<div class="limit">Display #<select id="limit_hikashop_category_information_module_222_50" name="limit_hikashop_category_information_module_222_50" class="inputbox" size="1" onchange="this.form.submit()">
<option value="20" selected="selected">20</option>
<option value="5">5</option>
<option value="10">10</option>
<option value="15">15</option>
<option value="20" selected="selected">20</option>
<option value="25">25</option>
<option value="30">30</option>
<option value="50">50</option>
<option value="100">100</option>
<option value="0">all</option>
</select>
</div><span class="pagenav_start_chevron"><< </span><span class="pagenav pagenav_text">Start</span><span class="pagenav_previous_chevron"> < </span><span class="pagenav pagenav_text">Prev</span> <span class="pagenav">1</span> <a class="pagenav" title="2" onclick="javascript: document.adminForm_hikashop_category_information_module_222_50_bottom.limitstart_hikashop_category_information_module_222_50.value=20; document.adminForm_hikashop_category_information_module_222_50_bottom.submit();return false;">2</a> <a class="pagenav" title="3" onclick="javascript: document.adminForm_hikashop_category_information_module_222_50_bottom.limitstart_hikashop_category_information_module_222_50.value=40; document.adminForm_hikashop_category_information_module_222_50_bottom.submit();return false;">3</a> <a class="pagenav" title="Next" onclick="javascript: document.adminForm_hikashop_category_information_module_222_50_bottom.limitstart_hikashop_category_information_module_222_50.value=20; document.adminForm_hikashop_category_information_module_222_50_bottom.submit();return false;">Next</a><span class="pagenav_next_chevron"> ></span> <a class="pagenav" title="End" onclick="javascript: document.adminForm_hikashop_category_information_module_222_50_bottom.limitstart_hikashop_category_information_module_222_50.value=40; document.adminForm_hikashop_category_information_module_222_50_bottom.submit();return false;">End</a><span class="pagenav_end_chevron"> >></span>
<div class="counter">Page 1 of 3</div>
<input type="hidden" name="limitstart_hikashop_category_information_module_222_50" value="0">
</div>
<span class="hikashop_results_counter">
Results 1 - 20 of 48</span>
</div>
<input type="hidden" name="filter_order_hikashop_category_information_module_222_50" value="a.ordering">
<input type="hidden" name="filter_order_Dir_hikashop_category_information_module_222_50" value="ASC">
<input type="hidden" name="18aa959f74c6262cdb2863f0ffaff82e" value="1">
</form>
We have talked to the hikashop people about this and they say we need to update to their most recent version (our version is just one below the latest one) but we have made some major mods to the code to include some of the clients requests so we do not want to lose those changes (maybe in the future we will update to the latest version, but for now we just want to know if there is a quick fix for this).
Is the form really vulnerable to cross-site scripting attacks? what can we do to protect it or make godaddy site scanner stop showing this warning message?
From the output of scanner he thinks that when he issued a request with additional parameter:
<<<<<<<<<<foo"bar'314>>>>>=1
and this param got printed what we can see in output:
type-atom?<<<<<<<<<<foo"bar'314>>>>>=1
that could mean that your page is prone to XSS, but many of those scanners forgets encodings... the same issue is for example with scannig LifeRay with w3af. But your html code prints:
%3C%3C%3C%3C%3C%3C%3C%3C%3C%3Cfoo%22bar'204%3E%3E%3E%3E%3E
So it seems that the param althogh appended, is escaped... so it is not strictly prone to XSS. If you want to know more visit XSS - Cheat Sheet, and you can use some other vuln scanners/proxies to confirm this issue: ZAP, WebScarab, w3af.