i want to monitor and send packet. i capture packets with wireshark and send packet with tcpreplay.my broblem is: when send packet with tcpreplay packet send sucssful, but nothing happen.
example 1 i open a address (www.mysite.com/test.php?id=1) whit browser.
after every visit that page in db of mysite a counter increase.
i want do example 1 with packets. i capture packet and send pcap file with tcpreplay but in db of my site nothing happen. why ??
example 2 i send a pm in yahoo messanger to my freinds and capture packet and send captured packet with tcpreplay or with sendpacket software
this packet recorded with tcpdump. when send that with tcpreplay in my site conter nothin happen
Ôò¡ ÿÿ ¤_ïTP™ J J ÄnÝ-¶ 'Ý'ç E <Ni# #«ÃÀ¨M.P–“‚ P ËÆ¿ 9#¾ ´
ˆÖ ¤_ïTI
B B ÄnÝ-¶ 'Ý'ç E 4Nj# #«ÊÀ¨M.P–“‚ P ËÆÀ_Ö/€!#¶
‰tmm¤_ïTÄ v v ÄnÝ-¶ 'Ý'ç E hNk# #ª•À¨M.P–“‚ P ËÆÀ_Ö/€!Q
‰tmmGET /mani/test.php?t=1 HTTP/1.1
Host: dgmobile.ir
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.2) Gecko/20100101 Firefox/10.0.2
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip, deflate
DNT: 1
Connection: keep-alive
¤_ïTŽ¡
B B ÄnÝ-¶ 'Ý'ç E 4Nl# #«ÈÀ¨M.P–“‚ P ËÇô_Ö0€§#¶
‰Ztn”¤_ïTÅ
B B ÄnÝ-¶ 'Ý'ç E 4Nm# #«ÇÀ¨M.P–“‚ P ËÇô_Ö0“€§#¶
‰[tn—
Related
So I was testing my website and I tried connecting with the TRACE http method. In response I got a massive string. I don't know what it is. Does anybody know what could it be and if it's some sort of vulnerability?
This is the string I'm talking about:
VFJBQ0UgLy5odHBhc3N3ZCBIVFRQLzEuMQ0KSG9zdDogd3d3LnNzZmt6LnNpDQpVc2VyLUFnZW50OiBNb3ppbGxhLzUuMCAoWDExOyBMaW51eCB4ODZfNjQ7IHJ2OjkxLjApIEdlY2tvLzIwMTAwMTAxIEZpcmVmb3gvOTEuMA0KQWNjZXB0OiB0ZXh0L2h0bWwsYXBwbGljYXRpb24veGh0bWwreG1sLGFwcGxpY2F0aW9uL3htbDtxPTAuOSxpbWFnZS93ZWJwLCovKjtxPTAuOA0KQWNjZXB0LUxhbmd1YWdlOiBlbi1VUyxlbjtxPTAuNQ0KQWNjZXB0LUVuY29kaW5nOiBnemlwLCBkZWZsYXRlDQpDb25uZWN0aW9uOiBrZWVwLWFsaXZlDQpDb29raWU6IGpzQ29va2llV2FybmluZ0NoZWNrPWRlY2xpbmVkDQpVcGdyYWRlLUluc2VjdXJlLVJlcXVlc3RzOiAxDQpDYWNoZS1Db250cm9sOiBtYXgtYWdlPTAsIG5vLWNhY2hlDQpPcmlnaW46IGh0dHA6Ly93d3cuc3Nma3ouc2kNClByYWdtYTogbm8tY2FjaGUNCg0K
It's a Base64 encoded string. Decoded it looks like this:
TRACE /.htpasswd HTTP/1.1
Host: www.ssfkz.si
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Firefox/91.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive
Cookie: jsCookieWarningCheck=declined
Upgrade-Insecure-Requests: 1
Cache-Control: max-age=0, no-cache
Origin: http://www.ssfkz.si
Pragma: no-cache
Which per se does not really look like a security flaw and much rather like a basic implementation of the TRACE http method which states that the contents of the request shall be reflected in their entirety in the response body.
Interesting note though, looking at the specification:
A client MUST NOT generate header fields in a TRACE request containing sensitive data that might be disclosed by the response. For example, it would be foolish for a user agent to send stored user credentials [RFC7235] or cookies [RFC6265] in a TRACE request. The final recipient of the request SHOULD exclude any request header fields that are likely to contain sensitive data when that recipient generates the response body.
So ideally the response should not have contained the Cookie header (to fully comply with the specification by my understanding the client you used to send the requests should not have included them in the first place however).
From my laptop I initiated a POST request to my web server. The HTTP POST request looks something like this (when seen via POSTMAN console)
POST /api/fwupgrade HTTP/1.1
User-Agent: PostmanRuntime/7.24.1
Accept: */*
Cache-Control: no-cache
Postman-Token: 2b1e72fa-f43b-4fc9-9058-e78533c30f0f
Host: 192.168.71.24
Accept-Encoding: gzip, deflate, br
Connection: keep-alive
Content-Type: multipart/form-data; boundary=--------------------------572971355726244237076370
Content-Length: 222
----------------------------572971355726244237076370
Content-Disposition: form-data; name="FileName"; filename="help.txt"
<help.txt>
The content-length is indicated as 222. the file help.txt has the following characters only (for test I put 10 a)
aaaaaaaaaa
When I receive a http request on the server, I parse the request and I see the content-length as 222. Now my questions:
a) I assume this content length 222 includes the bytes after the line "Content-Length: 222" am I right? So this would mean the request body starts from
------------------572971355726244237076370
Content-Disposition: form-data; name="FileName"; filename="help.txt"
<help.txt>
Is this understanding correct?
b) Does the request body always follow the same format i.e after "Content-Length:" it begins and ends with the data of the file, in my case "help.txt"?
c) Assuming #a is correct, I calculate the actual data to be starting from the location after filename="help.txt" /r/n and then store this in a file on my server. However I get 58 surplus bytes after the aaaaaaaaaa. Any idea how am I supposed to interpret Content-length or how postman calculates the Content-length field?
Regards
a) Roughly yes.
b) It depends on the Content-Type (here: multipart/form-data)
c) You'll need a parser for multipart/form-data messages. See, for instance, https://greenbytes.de/tech/webdav/rfc7578.html
I am quite new to Fiddler and it looks like an awesome tool to me.
What i wanted to do is generate a sequence of POST requests.
Explaination:
POST https://www.website.com/user/login HTTP/1.1
Host: www.website.com
Connection: keep-alive
Content-Length: 552
Cache-Control: max-age=0
Origin: https://www.website.com
Upgrade-Insecure-Requests: 1
DNT: 1
Content-Type: application/x-www-form-urlencoded
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,/;q=0.8
Referer: https://www.website.com/user/login
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.9
Cookie: ASP.NET_SessionId=mpdxdkrjujkzchwblg1ys2y3; ai_user=u0IpN|2018-09-25T16:12:07.607Z; ai_session=+Ip5T|1537899054881.5|1537899121420.5
__VIEWSTATE=something here PageContent%24txtRoll=14600&ctl00%24PageContent%24txtDOB=01%2F01%2F2001&ctl00%24PageContent%24btn_submit=LOGIN
i want to make a loop of request such that the DOB field takes value like
01%2F01%2F2001
then, 01%2F02%2F2001
then, 01%2F03%2F2001
and so on.. keeping everything else same.
And if the response from server is Code:302 then stop the loop or otherwise if the value reaches 31 then too stop the loop.
Thanks in advance.
Any suggestions are welcome.
P.S. :Sorry for the messy question, i don't know how could i say it in simple words.
You need to write a script which will do that for you. Here's an article that might help you.
https://www.telerik.com/blogs/understanding-fiddlerscript
Personally I'd write a script that does the task in python or any other language you know using any http library
I am getting 400 Bad request - Your browser sent an invalid request. for the request. The request size is 28KB.
< HTTP/1.0 400 Bad request
< Cache-Control: no-cache
< Connection: close
< Content-Type: text/html
<
<html><body><h1>400 Bad request</h1>
Your browser sent an invalid request.
</body></html>
I have following configurations in my haproxy.conf
maxconn 100000
tune.bufsize 32768
tune.maxrewrite 1024
What is the right settings to solve 400 Bad request error.
based on this link: https://www.geekersdigest.com/max-http-request-header-size-server-comparison/
looks like the request header is too big. It should be smaller than 16K, which is the default header size limit
a typical sip packet looks like this
INVITE sip:bob#biloxi.com SIP/2.0
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bK776asdhds
Max-Forwards: 70
To: Bob <sip:bob#biloxi.com>
From: Alice <sip:alice#atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710#pc33.atlanta.com
CSeq: 314159 INVITE
Contact: <sip:alice#pc33.atlanta.com>
Content-Type: application/sdp
Content-Length: 142
so is it possible to embedd perl or tcl parser in c
I would use a packet sniffer in C. Then identify SIP protocol based on data, push it somewhere and parse it with Perl/TCL from there. Example:
http://www.tcpdump.org/sniffex.c, or you can build packet sniffer from Perl/TCL itself, very easy task just some considerations when handling TCP/UDP fragmentation